[cssom] Do not create CSS boxes for document of display:none iframe

[zcorpan]

I'm not sure which spec this belongs in, possibly CSSOM, but we need to define somewhere that in a viewport that has dimensions 0x0 document of a display:none iframe, we do not create any CSS boxes.

See whatwg/html#1813 (comment)

[bzbarsky]

That's not correct. Something like this:

<iframe style="width: 0; height: 0"></iframe>

should create boxes for stuff inside it. Pretty sure the web depends on that.

[zcorpan]

Oh, OK. Thanks! Updated OP.

[tabatkins]

This seems implicit? While we don't define how the inside of replaced elements work, we do still define that a display:none replaced element doesn't generate any boxes. We don't have a concept of "out-of-tree" boxes in CSS.

[bzbarsky]

We don't have a concept of "out-of-tree" boxes in CSS.

There's a separate "tree" inside the iframe, no? I mean, there's a CSS viewport...

[tabatkins]

Hmm, maybe. The concept is weird, but yeah, I guess the outer tree doesn't actually know what's going on inside the inner tree.

This is outside core-CSS concepts, since this is dictating something about a replaced element. CSSOM could define it.

[FremyCompany]

In Edge at least, properties like "offsetWidth" on those elements in the hidden iframe do return 0. If we can standardize around this approach, that would be great.

[bzbarsky]

Right, that's what offsetWidth returns for an element with no box.

[dmethvin]

I just wanted to mention the ticket that @markelog referenced above from jQuery. There are cases where people are expecting the iframe's document to be laid out even though it's hidden in the parent. We don't really want to just trap and ignore that in jQuery since it provides inconsistent results across browsers.

[bzbarsky]

The throwing thing, and computed style in general, is not really related to this discussion, except insofar as certain things returned from getComputedStyle are used styles.