[whatwg] overflow of seamless iframes

On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> > > Note that the default width and height are adjusted for seamless
> > > iframes to match the width that the element would have if it was a
> > > non-replaced block-level element with 'width: auto', and the height of
> > > the bounding box around the content rendered in the iframe at its
> > > current width, respectively.
> >
> > "The bounding box" is a bit ambiguous. If the content overflows
> > vertically above the iframe's viewport, does that contribute to the
> > height of the bounding box?
>
> As far as I can tell there is no ambiguity to the concept of the bounding
> box of the content in the canvas, especially given the way the initial
> containing block is forced to zero height.


What's the answer to my question then? Should I have been able to derive it
somehow?

> For greater seamlessness, I'd prefer to make the intrinsic height be the
> > height of the iframe's root element.
>
> Why would that be more seamless? Surely that would be less seamless if
> there were things like negative margins, since then you'd have unsightly
> scrollbars appearing.


You mean the scrollbars associated with the iframe viewport?

Well, viewport scrollbars are already a bit magical. The CSS initial value
of 'overflow' is 'visible', yet all browsers use 'auto' for viewport
scrollbars unless another value is propagated up from the root element or
HTML <body>. So I'd suggest that for seamless iframes, the viewport overflow
be 'visible' unless another value propagates up.

I just realized that using the height of the root element won't make much
sense if the root element is positioned. I'm not sure how much to care about
that.

> Plus, as dbaron suggested, we'd like 'overflow' to apply to the content
> > of seamless iframes so that horizontal and vertical overflowing content
> > can be rendered as if the iframe was a regular overflow:visible block.
> > (We might want to recommend that the UA style sheet contain "iframe {
> > overflow:hidden; }" to make it easier for authors to avoid spoofing
> > attacks via seamless sandboxed iframes using clever positioning.)
>
> Well, I guess I'm ok with that, but that will presumably require
> significantly changes to the CSS spec to define how it all works (e.g.
> with compositing and so forth).


We can make the iframe a stacking context. Then I don't see any problems
with compositing.


> The current definition is intended to be
> really easy to implement without needing any changes to the CSS model.
>

I think that's a good goal, but we also want it to be reasonably "seamless".

I'm concerned about the use case of very wide content in the iframe (i.e.
content overflowing the root element horizontally); for example a forum with
many wide messages, each of which is a seamless iframe. Right now it seems
the choices are to either have a horizontal scrollbar in each message or
clip each message horizontally, there's no way to make it work like a forum
page.

Actually I'm not 100% sure you mean by "the width that the element would
have if it was a non-replaced block-level element with 'width: auto'". You
mean if it was such a block-level element containing the root element of the
iframe's document?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080818/766f715c/attachment.htm>

Received on Sunday, 17 August 2008 22:13:20 UTC