Should the contents of display:none iframes really be considered as "being rendered"?

[bzbarsky]

A literal reading of the specs seems to say that a display:none iframe behaves in the following way:

1. It creates a viewport sized 0x0.
2. It then proceeds to do layout inside that viewport.

Claim 1 is supported by https://html.spec.whatwg.org/multipage/rendering.html#the-page:document kinda. There is no actual definition of what "being rendered" means for a browsing context, but I expect that it should be defined to mean the same thing as "being rendered" means for the browsing context container. Or something. This needs to be tightened up in the spec.

Claim 2 is supported by the fact that none of the mentions of "being rendered" in HTML say the stuff inside the subframe is not "being rendered". Note that this means that focusing things in that display:none iframe should work, per spec, and so forth.

I believe item 2 is a clear spec bug. Certainly allowing focusing things in display:none iframes (but not display:none things directly!) seems like a spec bug to me, and forcing UAs to do likely-expensive layout on the contents of display:none iframes seems weird.

It would be ideal if HTML and CSS could sort out this behavior between the two of them.

In terms of actual UA behavior, it looks like WebKit and Blink do in fact allow focusing things inside a display:none iframe [1]. Edge and Gecko do not. Gecko and Edge also do not perform box construction or layout inside display:none iframes [2].

It seems to me that the fast and sane thing of considering everything inside a display:none iframe as "not being rendered" is web compatible enough (given that this is what Edge and Gecko ship), that we should really consider speccing it.

[1] Testcase:

<iframe style="display: none" src="subframe.html"></iframe>
<script>
  onload = function() {
    frames[0].document.querySelector("input").focus();
    alert(document.activeElement);
    alert(frames[0].document.activeElement);
  }
</script>

where subframe.html contains a single <input> tag.

[2] Testcase:

<iframe style="display: none" src="subframe.html"></iframe>
<script>
  onload = function() {
    var win = frames[0];
    var s = win.getComputedStyle(win.document.querySelector("div"));
    alert(s.height);
 }
</script>

where subframe.html has <div>Hey</div>: this alerts "auto" in Edge.

/cc @annevk @tabatkins

[annevk]

So the main question here is whether WebKit and Blink (paging @smfr and @esprehn) are interested in optimizing display:none <iframe>s by not creating boxes for elements in such <iframe>s' documents.

[domenic]

I hear @zetafunction also knows things about Blink iframes. Daniel, do you think Blink is interested in optimizing display:none <iframe>s by not creating boxes for elements in such <iframe>s' documents, like Gecko and Edge do?

I tend to agree with @bzbarsky that given the 2/2 split, we should spec the more reasonable behavior of not creating such boxes. But it would be nice to get some opinions first.

[esprehn]

I support this change though I do worry it'll break some content. We'll have to try it.

[smfr]

Ditto for WebKit. I filed https://bugs.webkit.org/show_bug.cgi?id=162560

[esprehn]

Filed: https://bugs.chromium.org/p/chromium/issues/detail?id=650433

[domenic]

So I guess we should fix this in the spec by specifying somewhere that no CSS layout boxes are created for elements inside iframes that are not themselves being rendered. That is, changing the definition of "has CSS layout boxes" seems better than changing the definition of "being rendered".

I assume that will require CSS spec changes? @zcorpan, could you help us out here?

I'll submit a PR for the cleanup @bzbarsky mentions in the OP.

[bzbarsky]

That is, changing the definition of "has CSS layout boxes" seems better than changing the definition of "being rendered"

Yes, I agree.

[zcorpan]

Filed w3c/csswg-drafts#571 for the CSS side

[erikchen]

When we implemented this in Blink we discovered that there's a fairly common pattern among web developers to call Window.print() on display:none iframes. We updated our implementation to allow layout of display:none iframes during a call to Window.print(), which appears to match the behavior of other JS implementations. Should we update the spec to include this caveat?

[chrishtr]

Also, the Window.print functionality exists in both Firefox and Safari, so there does appear to be
a de facto standards quirk in this situation.

[bzbarsky]

Note that print(), in Firefox, creates an immutable clone of the document and prints it asynchronously. It does not lay out the actual document involved in any sort of print mode, so it's not a quirk in that sense: the thing being laid out is not the thing in the display:none iframe at all.

Yes, this is quite different from the behavior of Blink, which messes with the actual being-shown document. Of course the spec for print() is fairly handwavy....

[andreasonny83]

Short answer YES. In my opinion, the content of a display:none iframe should always render.
Here's why and it's very simple.

An iframe is basically like a browser inside another browser and it allows developers to display contents coming from the outside WWW, so it's basically like a window into another dimension.
Given that the previous assumption is correct, then the fact that that window is hidden, should not, in any way, alter the functionality of the targetted dimension. If this cannot be guaranteed then there will be unpredictable consequences on the targetted website.
If, for instance, a website is doing some rendering in the background based on some HTML element dimensions, then the result of that calculation will be compromised by the fact that the website is rendered inside a hidden iframe which is only fine as long as the iframe is not visible. But, when the user toggles that visibility, then the rendered content in the iframe will be useless because compromised by external factors not in control by the targetted website.
Starting from Chrome v74 this bug can be easily reproduced as I reported on this bug https://bugs.chromium.org/p/chromium/issues/detail?id=963876. However, the Chromium team doesn't consider this as a bug

[chrishtr]

The problem is that the size of an iframe, whether it renders anything, and even when it renders,
is controlled by its parent. Also, your proposal has serious performance implications. It's really important not to do unnecessary rendering work.