[whatwg] overflow of seamless iframes

Sun Aug 17 23:45:42 PDT 2008

On Mon, 18 Aug 2008, Robert O'Callahan wrote:
> 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?

I don't understand the question. How does the viewport affect the bounding 
box?

> > > 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?

Right.

I just thought of another problem with allowing the contents of a 
"seamless" iframe to overflow outside the iframe box.

One of the main uses for this will be to sandbox blog comments, using the 
yet-to-be-defined doc="" attribute, as in:

   <iframe doc="<!DOCTYPE HTML><p>You suck"
           seamless sandbox="allow-same-origin"></iframe>

If we allow the contents to flow out of the box, then we also allow blog 
comments to start overlapping other content on the page.

> > 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.

The way forum pages work now is that the content ends up screwing up the 
rest of the page, so I think that's a good thing. :-) People work around 
this now by forcing line break opportunities to exist in long URLs, etc, 
or by setting overflow:auto on user-submitted content.

> 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?

I guess if the element is itself in an element that is shrink-wrapping, 
the current spec is underdefined. I'm not sure what width would be the 
right width at that point. Zero? The narrowest width for which increasing 
the width by one pixel doesn't decrease the height or decrease the number 
of line breaks?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'