On Tue, May 20, 2025 at 12:05 AM Jake Archibald <jaffathec...@gmail.com> wrote:
> I think the "one shot" nature of this means it misses a lot of use-cases, > such as the Discus case given in the explainer. Could the size be updated > continually with the same constraints applied to CSS containers? This would > also allow size to be set sooner than the load event, which would perform > better, given how late the load event fires (after all images have loaded > etc). That would be ideal, if we can find a way. The reason for the restriction in the current prototype is to avoid hysteresis and infinite layout loops (as well as poor performance generally). For example, if the iframe content is sized to 120% of the viewport, then repeatedly laying it out will make the <iframe> in the parent document larger and larger on every layout. One way to avoid this problem could be to perform the layout with the same starting size for the <iframe> on every layout of the child frame... > On Tuesday, 20 May 2025 at 00:43:20 UTC+2 Chromestatus wrote: > >> Contact emails chri...@chromium.org >> >> Explainer >> https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md >> >> Specification None >> >> Summary >> >> Allow sites to opt into iframes having responsive sizing (sizing the >> <iframe> element in the parent document to the iframe document's layout >> overflow sizing, so that scrolling in the child document is avoided). >> >> >> Blink component Blink>Layout >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELayout%22> >> >> Motivation >> >> This is a natural feature to have for iframes, when the site wants to >> render the iframe content so that it looks seamless with the parent frame >> and avoids scrollbars. >> >> >> Initial public proposal https://github.com/whatwg/html/issues/555 >> >> TAG review None >> >> TAG review status Pending >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals Plenty of developer demand is expressed in >> the feature request standards issues: >> https://github.com/whatwg/html/issues/555 >> https://github.com/w3c/csswg-drafts/issues/1771 >> >> *Other signals*: >> >> WebView application risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> None >> >> >> Debuggability >> >> None >> >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? No >> >> Flag name on about://flags None >> >> Finch feature name None >> >> Non-finch justification None >> >> Requires code in //chrome? False >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5108373464547328?gate=5167068974153728 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/021eff09-9e71-4b5b-ad33-ce550e87c744n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/021eff09-9e71-4b5b-ad33-ce550e87c744n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_3WvYP6w5niRUc0%3DXkZzZyHTxVPxfqT4ncvTsXnf6JDg%40mail.gmail.com.
