Collection of security review: - Does the feature include consideration of fenced frame? - Although the new exposed information seems to be minor and only exposed when both side opt-in, could you please note down the risk in spec later? If you want to low down the risk even more, you can consider adding allow site list in meta tag for example, but in this case the risk is really low so this is just a remind of posibility. From a security pespective, we are happy to approve the feature anyway.
On Friday, May 23, 2025 at 6:37:25 PM UTC+2 Chris Harrelson wrote: > I filed a spec issue <https://github.com/w3c/csswg-drafts/issues/12229>, > let's continue the discussion there. > > On Thu, May 22, 2025 at 10:44 PM Jake Archibald <jaffat...@gmail.com> > wrote: > >> Wouldn't the answer be to make the viewport units behave like container >> query units? >> >> It feels like container queries hit all these problems and came up with >> solutions. There may be additional issues, but it seems like a better >> starting point. >> >> On Thu, 22 May 2025, 18:17 Chris Harrelson, <chri...@chromium.org> wrote: >> >>> On Tue, May 20, 2025 at 12:05 AM Jake Archibald <jaffat...@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+...@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+...@chromium.org. >> > To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ5xic-sb%2B%2B94EmYPuGbaL0PHN%2BJfD2X7dnn9zS-emHEA%3D6S2Q%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ5xic-sb%2B%2B94EmYPuGbaL0PHN%2BJfD2X7dnn9zS-emHEA%3D6S2Q%40mail.gmail.com?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/787ad700-a018-45ca-92c0-7ea13131add9n%40chromium.org.
