- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 18:03:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] What is the snapshot containing block for iframes?`, and agreed to the following: * `RESOLVED: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block` * `RESOLVED: If the SCB of an iframe exceeds an implementation defined maximum, the UA can skip the transition` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> khush: defining the snapshot used for the block in the transition<br> <TabAtkins> khush: defined with two things in mind<br> <TabAtkins> khush: one was, this whole pseudo-dom we're making, how is it positioned in the doc during layout<br> <TabAtkins> khush: two was, which dom do you capture<br> <TabAtkins> khush: on mobile viewports, you have some part of UI that can be retracted (url bar, root scrollers)<br> <TabAtkins> khush: we want it so that if going A->B, capture the largest chunk of window that can potentially display page content, even if interactive widgets are hidden<br> <TabAtkins> khush: this is very specific to the top-level frame, we didn't describe iframes well<br> <TabAtkins> khush: implicitly it ended up being the ICB of the iframe.<br> <TabAtkins> khush: iframes can be scrolled offscreen, so trying to define it as the on-screen viewport doesn't map well<br> <TabAtkins> khush: so one proposal is for iframes, say the snapshot containing block is the ICB<br> <TabAtkins> khush: but someone filed a bug where they had a massive iframe, and it causes an OOM for us<br> <TabAtkins> khush: so either we define a way to clip the iframe snapshot to be reasonable sized, or give an affordance to the UA to skip the transition<br> <TabAtkins> khush: it seems like an edge-case people won't generally hit<br> <khush> q?<br> <TabAtkins> khush: So second proposal is if snapshot containing block exceeds a UA-defined max size, we can skip the transition<br> <fremy> q+<br> <bramus> scribe+<br> <bramus> TabAtkins: (missed)<br> <bramus> khush: (missed2)<br> <TabAtkins> TabAtkins: We already allow UAs to implicitly do whatever they need for OOM conditions. Good to call them out if they might be common, but don't *need* an explicit allowance for it.<br> <bramus> s/(missed)//<br> <bramus> s/(missed2)//<br> <TabAtkins> khush: The question here is because there' two design choices. One is, when this came up for elements, if you have a massive element, the spec recommends capturing at least the on-screen portion fo the element<br> <TabAtkins> khush: For iframes - for OOPIFs it's hard to track where on the screen the iframe is<br> <TabAtkins> (out of process iframes)<br> <TabAtkins> khush: So the question was if we should try to figure out where the iframe is and capture the ons-creen part, or just say "you amde a massive iframe, sucks to be you"<br> <miriam> ack fremy<br> <khush> q?<br> <TabAtkins> fremy: I was wondering why we special-case iframes, but khush seems to have answered that<br> <TabAtkins> fremy: is it really a little difficult, or *impossible* to tell this? good for consistency if possible.<br> <TabAtkins> fremy: But also agree with TAb, if you'rea bout to crash the browser do whatever you need to avoid that.<br> <TabAtkins> fantasai: So I think the OOM condition doesn't *have* to be in the spec<br> <TabAtkins> s/fantasai/fremy/<br> <TabAtkins> fremy: so if you have a big document but a small iframe, are you snapshotting the hwole document or the part that's scrolled?<br> <TabAtkins> khush: a screenshot of the iframe bounds. for the embedded dcument that's what we'll define the containing block as<br> <TabAtkins> fremy: So this is only an issue if the <iframe> element is very big, not if the content of the iframe is big<br> <TabAtkins> khush: yes<br> <miriam> q?<br> <TabAtkins> khush: to answer how difficult, i think because of web features like intersectionObserver, we do send this info to the embedded document, but I haven't looked into the details yet<br> <TabAtkins> khush: I'd like to take the massive iframe resolution now, and we can revisit if necessary to do a more correct thing<br> <khush> res 1: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block<br> <khush> res 2: If the SCB exceeds an implementation defined maximum, the UA can skip the transition<br> <TabAtkins> miriam: So any objections to first resolution?<br> <TabAtkins> RESOLVED: Snapshot Containing Block for an iframe should be that frame's Initial Containing Block<br> <TabAtkins> astearns: question - just for iframes?<br> <TabAtkins> khush: yes<br> <TabAtkins> astearns: then second resolution should specify that<br> <TabAtkins> RESOLVED: If the SCB of an iframe exceeds an implementation defined maximum, the UA can skip the transition<br> <TabAtkins> fantasai: Did we need a similar resolution for the main window?<br> <TabAtkins> astearns: For main if already scopes to the visible rect<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9786#issuecomment-1939259536 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 18:03:15 UTC