- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 27 Jan 2026 18:09:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Auto-resize iframes based on content`, and agreed to the following: * `RESOLVED: The first instance of the meta tag for this feature is immutable once parsed` * `RESOLVED: Define frame-sizing with various height and with keywords, with default of auto` <details><summary>The full IRC log of that discussion</summary> <koji> https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-3607718468<br> <bramus> koji: want to discuss chris’s comment on the issue<br> <bramus> … looking for feedback on most recent ED<br> <lwarlow> q+<br> <bramus> … if anyone has feedback, we’d appreciate<br> <bramus> astearns: has anyone had a chance to look into this ED?<br> <bramus> … seeing some heads shaking<br> <bramus> … koji, would you like this to be “PTAL” and move on to the rest, or want to summarize the changes?<br> <bramus> koji: I believe Chris already asked a few weeks ago.<br> <emilio> q+<br> <bramus> … if anyone has anything, or wants more time …<br> <bramus> iank_: can do a high level overview, if that would be helpful<br> <oriol> q+<br> <bramus> … basically, this is trying to sovle the problem of having iframes grow based on their contents<br> <bramus> … now due to the way they work, this is somehwat difficult (cycles)<br> <bramus> … what this does, is you need to opt in both sides<br> <bramus> … meta tag in the iframe<br> <bramus> … and then from the parent side you opt-in via contain-intrinsic-size<br> <bramus> … at the moment, what happens is the that the scroll height repalces the natural size on the parent<br> <bramus> … and then replace-siziung happens as normal<br> <bramus> … that message, at the moment, happens on DOMContentLoaded<br> <bramus> … (exact timing can be discussed)<br> <bramus> … dont want to do this every time the scroll changes<br> <bramus> s/scroll/scrollheight<br> <bramus> … other mechanism is via script inside of the iframe<br> <bramus> … iframe loads content dynamically (e.g. a comment widget) and then fires event upwards<br> <bramus> … window.requestResize<br> <bramus> … that is high level overview<br> <bramus> … open questions are:<br> <bramus> … What CSS property triggers this? c-i-s or new one?<br> <bramus> … subissue is that we currently have it hooked up to height … want to opt in to only 1 dimension, 2 is tricky … but maybe you want both?<br> <emilio> q+<br> <bramus> … next thing is about the timing: script for dynamic use-case, but what is most useful timing for doing it automatically<br> <bramus> koji: Yes, looking for feedback on the property name<br> <bramus> … whether `contain: size` is required or ont<br> <bramus> … want to also minimize the number of ???<br> <bramus> … whether it is OK for the meta tag be mutable<br> <bramus> iank_: that should be fine<br> <astearns> ack lwarlow<br> <bramus> lwarlow: does this work for cross=-origin iframes? or only same-origin?<br> <bramus> koji: also cross-origin<br> <bramus> lwarlow: is that not a new comms mechanism?<br> <bramus> koji: are you talking about privacy concerns?<br> <bramus> lwarlow: yes, from users end :… the two props opting in seems fine, but cross-channel comms<br> <bramus> iank_: you already have that<br> <bramus> … the parent can change the size and that is that direction<br> <bramus> emilio: but it is not ???<br> <bramus> iank_: like a resizeobserver?<br> <bramus> emilio: right now you need to postmessage<br> <bramus> iank_: from my persepective this isnt adding anything new in comms terms … already exists from both sides<br> <bramus> lwarlow: fair enough<br> <bramus> … as its opt-in<br> <bramus> lwarlow: I think cross-origin is the most interesting use-case here<br> <bramus> iank_: yes<br> <bramus> astearns: if there is an opt-in for not allowing post-message, this should also cover this?<br> <bramus> iank_: that is the policy with the meta, to say that they are OK with broadcasting the info<br> <astearns> ack emilio<br> <dholbert> q+<br> <bramus> emilio: regarding timing … feels simliar tlike scrolltoref code<br> <bramus> … in gecko that is also DOMContentLoaded and Load<br> <bramus> … matches what is being proposed, but might have some subtleties<br> <bramus> … seems worth being consistent<br> <bramus> … roughly around the same time as scrolltoref algo<br> <bramus> iank_: does that sound reasonable, koji?<br> <bramus> koji: not familar with that part of the code<br> <smfr> q+<br> <bramus> emilio: domcontentloaded is the earliest event, and load is the latest where you can know it … would be good to double check<br> <bramus> iank_: was there 1 other case where we trigger this automatic thing?<br> <bramus> koji: just the two events mentioned<br> <bramus> … can I confirm that emilio to mirror scrolltoref?<br> <bramus> iank_: emilio is saying to be consistent with it, timing-wise<br> <bramus> emilio: same assumption that we are making: scrollheight will be right at those events and time<br> <astearns> ack oriol<br> <bramus> oriol: dont think this should be bolted on top of size containment, so prop should not be c-i-s<br> <bramus> … should c-i-s surive when the iframe navigates to other document<br> <bramus> iank_: I would expect no<br> <bramus> emilio: there is precedent for this: svg img in object that auto-size, it also goes away when you navigate out<br> <TabAtkins> I also would expect no, we'd revert it to the default size (unless the new page also opts in)<br> <bramus> iank_: makes sense<br> <bramus> … good food for test case<br> <bramus> smfr: so what happens to the iframe when you navigate?<br> <bramus> emilio: it might get clobbered by the next thing<br> <bramus> smfr: if the next thing has the meta tag?<br> <bramus> iank_: it loses the natural size<br> <astearns> ack dholbert<br> <bramus> dholbert: sounds like sth an author could polyfill with postmessage<br> <emilio> q+<br> <bramus> … as content loads, incremental updates<br> <bramus> … sounds like that would likely paint inside the smaller iframe size, and then the iframe would grow<br> <bramus> iank_: yes, cross-origin different ???<br> <bramus> … impl could frame block for a few frames<br> <astearns> ack smfr<br> <bramus> dholbert: but not part of the design<br> <bramus> smfr: domcontentloaded feels too early<br> <bramus> … load … that would be the rendering event _after_ the load<br> <bramus> emilio: scrolltoref happens before the update, so you can see the scroll<br> <bramus> smfr: but if th econtent mutates after the<br> <bramus> iank_: there is a task that gets ???<br> <bramus> emilio: if its a task then you could render in-between<br> <bramus> iank_: <missed><br> <bramus> smfr: I can see this being used on payment flow, that typically has multiple navigations<br> <bramus> … seems like a hard thing for impl to do<br> <astearns> s/<missed>/so we’ll take this as an action to precisely specify timing/<br> <bramus> emilio: if you have intrinsic height, the navigation would clobber it but only at the point the next page is domcontentloaded/load<br> <bramus> … seems like less opportunities fro jumping around<br> <dholbert> s/multiple navigations/multiple navigations where the payment-flow provider would have to take care to specify the meta tag at each point to avoid the iframe resizing/<br> <bramus> smfr: is there experience with this so far?<br> <bramus> iank_: a lot of the payment markets do navigate a lot<br> <bramus> … maybe we clear the natural size, and get feedback from authors and can re-evaluate<br> <astearns> likely should have a navigation example in the spec<br> <bramus> smfr: so if you do navigate, you keep the old size you keep the old size until the domcontentloaded or snap back to 0?<br> <bramus> iank_: not to 0 but default object size<br> <bramus> … (I think)<br> <bramus> koji: current code does not do anything right now … upon navigation we keep current size, and then on next domcontentloaded it resized<br> <bramus> iank_: we may be accidentally doing what smfr is suggestions<br> <bramus> smfr: so new doc might have info about previous doc<br> <bramus> … needs more thinking<br> <bramus> iank_: needs follow up issue<br> <bramus> fantasai: if the prvious and next do are ont he sam eorigin, this is fine<br> <bramus> iank_: technically this already exists if you polyfill this via postmessage<br> <bramus> emilio: but the top level page needs to coordinate<br> <lwarlow> q<br> <bramus> fantasai: but in this case it is less likely that the author will know<br> <fantasai> They might do it unintentionally<br> <bramus> iank_: will fill isssue and follow-up<br> <fantasai> Just because they want the sizing behavior<br> <astearns> ack dbaron<br> <bramus> dbaron: wanted to react about scrolltoref timing: feel like that timing is bad tha twe have built new platform features that work around ???<br> <bramus> emilio: maybe we should make it better<br> <dholbert> s/???/how bad it is/<br> <bramus> dbaron: if ?? made it better … i would be hesitant to mirro rscorlltoref timing<br> <bramus> emilio: it is doing the same thing. like scroll-anchoring is keeping the scroll pos … if you do this thing … this issue has same features. if somebody add image after load<br> <bramus> dbaron: am suggesting that scorlltoref is too infrequent<br> <dholbert> s/after load/after load, then the image will overflow/<br> <bramus> … and scrolltoref+scrollin gtiming is like more useful<br> <bramus> emilio: but then you get into that cyclic issue we are trying to prevent<br> <bramus> dbaron: yes, missed the cyclic issue<br> <bramus> emilio: every time scrollheight grows, then re-rerunning would cause cycles<br> <bramus> … that is why a pretty infrequent timing is proposed<br> <bramus> iank_: needs an affixed number of times this gets invoked<br> <astearns> ack emilio<br> <bramus> emilio: doing thi sin both axis seems useful<br> <bramus> … web extension folks often complain about popover sizes being incompatible across browsers<br> <bramus> … we have code in gecko to autosize<br> <bramus> … should not do this to begin with, but is possible<br> <bramus> iank_: was trying to avoid both axis at the same time, as every browser does auto=sozing differently (we do min-content)<br> <bramus> emilio: we do ???<br> <bramus> iank_: gets more broken if you do orthogonal writing modes<br> <bramus> … there is a few different things you can do:<br> <bramus> … - scrollheight seems easiest<br> <bramus> … - html height could also be considered<br> <bramus> … I think scorllheigt is most useful<br> <bramus> emilio: i agree<br> <bramus> iank_: what about orhtogoanl layouts?<br> <bramus> … scrollwidth is easiest<br> <bramus> … (most logical)<br> <bramus> … both axis … I dont anyone uses scrollwidth/scrollheight for that<br> <bramus> … I would like to punt the both axis case, and do one or the other initially<br> <bramus> … but if you really know what you are doing, but the guardrails are less on that<br> <bramus> emilio: fine with punting<br> <bramus> … but saying you could design the feature to have it solved in the future<br> <bramus> … especially for web content<br> <Kurt> q+<br> <bramus> iank_: it is basically a request to update the sizes<br> <bramus> emilio: maybe someone should opt in to one of the sizes<br> <bramus> iank_: and this gets into the next issue … whatever this prop will be … like from-width, from-height, …<br> <bramus> … or from-scroll-width (and logical ones)<br> <bramus> … would be how I could design it<br> <bramus> emilio: makes sense<br> <bramus> … brought it up to not block it<br> <bramus> … ideally, extension popups do this weird thing with RO<br> <bramus> … if the popup could just request an auto size, that would solve that<br> <bramus> iank_: popup stuff would most likely require a few passes<br> <astearns> ack fantasai<br> <bramus> fantasai: if we do solve both axis, we could use a new keyword with width and height<br> <bramus> … if not, we could use frame-sizing<br> <bramus> … was for what to measure: alternative is scrollable content area<br> <astearns> s/frame-sizing/frame-sizing since we have form-sizing/<br> <bramus> … that wont grow if you have things animating in or out<br> <bramus> … like basically the in-flow scrollable area<br> <bramus> iank_: that is equicalent to the html size<br> <bramus> fantasai: for the height yes, not width<br> <bramus> … html is always as wide as the ICB<br> <bramus> … but content scrollable area …<br> <bramus> … would need to look into that<br> <bramus> … not a useful definition<br> <bramus> … breaks the ??? principle<br> <fantasai> s/???/div transparency/<br> <bramus> iank_: reason why I was OK with scrollheight was bercause it is effectively a one shot<br> <bramus> … the scrolalble area: people might but height: 100% on HTML and overlfowing body, so we wont capture that<br> <bramus> fantasai: triggering measurement on the load event and stuff makes sense<br> <bramus> … having an API also makes sense<br> <bramus> … but other cases (like expanding accordion): could make details opening and closing a trigger could be useful here<br> <bramus> iank_: might be OK<br> <bramus> … should maybe be part of the meta tag, to have folks opt-in<br> <bramus> … by default domcontentloaded and load, and then add more optoins<br> <bramus> fantasai: some things like details should maybe be default, and then opt out<br> <bramus> emilio: I think problem is that it not easy determing when you want to compute the size … details migth be a sidebar and stuff might have move in between … so might be bad that you recalced<br> <bramus> iank_: it would snap again for no obvious reason<br> <bramus> … have done similar thought process, to do it – for example – on network events, but comes bad user experience<br> <bramus> emilio: like style sheet lods<br> <bramus> iank_: yes. mimimum useful is domcontentloaded and load + the scrip hammmer<br> <bramus> … additional opt-ins can be considered<br> <astearns> ack Kurt<br> <Kurt> https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element/view<br> <bramus> Kurt: edge case thing: If you have SVG in an iframe, the view element can specificy the viewbox and the fragment URL can take different values, which should trigger a resize as well? It’s a URL chagne without a navigation<br> <bramus> iank_: can file an issue for that case<br> <bramus> astearns: currently past the first bullet of the three in the issue<br> <bramus> … should we discuss mutability?<br> <bramus> iank_: I think we discussed that and it should be immutable<br> <bramus> astearns: should we take a resolution?<br> <bramus> astearns: PROPOSED RESOLUTION: The meta tag for this feature is immutable<br> <bramus> smfr: from the beginning of time, or snapshotted at DCL?<br> <bramus> koji: Only by parser<br> <bramus> smfr: if it is multiple: first or last?<br> <TabAtkins> "first" is immutable<br> <bramus> iank_: we will document it<br> <fantasai> +1<br> <bramus> … and come back to that if its a bad idea<br> <TabAtkins> so yeah, when parser either hits the first <meta> of this type, or closes the <head>, it should consider the value frozen.<br> <TabAtkins> imo<br> <bramus> astearns: amened resolution is that the first meta tag immutable once parsed<br> <lwarlow> +1<br> <bramus> RESOLVED: The first instance of the meta tag for this feature is immutable once parsed<br> <bramus> koji: can we also resolve on contain: size?<br> <bramus> astearns: next issue is about c-i-s require contain: size<br> <oriol> Does document.write count as parsed?<br> <bramus> … is that same thing?<br> <bramus> iank_: I think we want to change the property and not ??<br> <iank_> `frame-sizing: content-width | content-height | content-block-size | content-inline-size | none`<br> <bramus> … resolve that its a new property named frame-sizing<br> <bramus> … and then TBD the keywords<br> <emilio> q+<br> <bramus> koji: and we also need a default<br> <bramus> iank_: that would be none<br> <bramus> koji: I mean a default size before receiving the first<br> <bramus> emilio: maybe we can explain the object svg sizing with this keyword?<br> <bramus> … was thinking: is it useful to explain svg, but maybe no because you can override it<br> <bramus> … mabye dont need that<br> <koji> `frame-sizing: [content-width | content-height | content-block-size | content-inline-size | none] <lenght>?`<br> <bramus> fantasai: are these keywords using the writing of the embedding iframe or of the embedded dcoucment<br> <bramus> iank_: of the parent<br> <bramus> emilio: other question is: would this apply when you have an SVG doc embedded?<br> <bramus> … in that case, if the default is none, its weird<br> <bramus> … so maybe should be auto<br> <bramus> dholbert: is the scrollheight interesting with an SVG doc?<br> <bramus> … even if the SVG declares a large size, if you put in an iframe that size would be respected<br> <bramus> … (at least large viewbox)<br> <bramus> ChrisL: the viewbox is irrelevant to the size if you declare a<br> <fantasai> frame-sizing: fixed | ...<br> <bramus> emilio: maybe default to auto<br> <bramus> iank_: can file an issue about how SVG docs should work<br> <bramus> astearns: so elika,. you suggested fixed<br> <bramus> fantasai: because field-sizing uses fixed and content<br> <bramus> … if its auto then it should be auto, but if its none then it should be ???<br> <bramus> … if you put SVG in an iframe, does it size the same as ??<br> <astearns> s/???/fixed instead/<br> <bramus> iank_: it has a full document<br> <bramus> emilio: but a subdocument<br> <bramus> fantasai: will it size to its content<br> <bramus> emilio: it gets the aspect ratio form the doc<br> <oriol> q+<br> <bramus> iank_: can take an issue for that<br> <astearns> ack emilio<br> <bramus> fantasai: and dpeending on that do auto or fixed<br> <bramus> iank_: can do auto initially<br> <astearns> ack oriol<br> <bramus> oriol: got lost about what auto is supposed to address<br> <bramus> iank_: trhing to cover the svg-in-iframe<br> <bramus> emilio: it is s the apsect ratio<br> <bramus> oriol: svg in iframe has special treatment?<br> <bramus> emilio: yes, svg propagates ar to the embedder<br> <kizu> Random semi-related fun article about SVG and sizing, where it exploits streaming SVG with animations to continuously update its size: https://dev.to/janeori/100-css-fetch-and-exfiltrate-512-bits-of-server-generated-data-embedded-in-an-animated-svg-5aad, could be an interesting edge case to consider.<br> <bramus> Kurt: and that ar can change on the url fragment<br> <astearns> `frame-sizing: [content-width | content-height | content-block-size | content-inline-size | auto] <length>?`<br> <bramus> astearns: we are definitely gonna need an issue for<br> <bramus> … that<br> <bramus> astearns: is this the syntax I posted?<br> <bramus> fantasai: are we including length, or reusing some other?<br> <bramus> iank_: problem with throwing length in there is that you need contain: size, which would make us ignore this property<br> <bramus> … maybe can specify like c-i-s without contain: size but would be weird<br> <fantasai> PROPOSED: Define `frame-sizing: auto | content-width/height/block-size/inline-size` to define which axis draws from the iframe content. Rename auto to fixed if SVG is not magical enough to require auto.<br> <bramus> … using koji’s suggestion to putting default in here would make sense from that perspective<br> <bramus> fantasai: so we …<br> <bramus> iank_: so c-i-s needs contain: size, and contain: size will make you ignore all of the content … so its 0 or c-i-s value. If you set frame-sizing (like field-sizing) to content might not do anyting if you have those other two<br> <bramus> … problem is that cis requires c:s and you cant use cis with the new prop<br> <oriol> +1<br> <bramus> … unless we make it work when you get ???<br> <bramus> fantasai: we could say that it has no effect if you have either contain or frame-sizing<br> <bramus> … would rather do that, than introduce othe rproperty<br> <bramus> iank_: concern is that it has c-i-s in the name<br> <bramus> fantasai: maybe rename it<br> <bramus> iank_: fine with reusing that<br> <oriol> q+<br> <bramus> koji: in this issue oriol said ???<br> <astearns> ack oriol<br> <bramus> oriol: it has contain in the name, so it should only be for size containment, dont like the idea of using it for this also. little overlap that I would prefer including into frame-sizign<br> <koji> s/???/should require not contain:size<br> <koji> s/???/should require not contain:size/<br> <bramus> fantasai: I can see why you woulnt want to shove the length in the sam eproperty<br> <bramus> iank_: can resolve for now on frame-sizind and keywords, and file issue for default sizing<br> <bramus> astearns: Is that OK with you koji and oriol? to not add length for now and file new issue for it<br> <bramus> PROPOPSED RESOLUTION: Define frame-sizing with various height and with keywords, with default of auto<br> <bramus> RESOLVED: Define frame-sizing with various height and with keywords, with default of auto<br> <bramus> smfr: this is just about iframe and also object?<br> <bramus> chrisl: why would object be different?<br> <bramus> iank_: can take it as an issue<br> <bramus> fantasai: does svg have different people between iframe and ??<br> <bramus> dbholbert: it does<br> <smfr> s/??/object/<br> <bramus> s/people/behavior<br> <bramus> iank_: thank you for the discussion, and we’ll file some follow-up issues<br> <dholbert> specifically if you put an SVG with large height/width/viewBox into an iframe, then we put the iframe at the default object size and we let the SVG overflow and have large scrollWidth and scrollHeight<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-3806716273 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 January 2026 18:09:41 UTC