Re: [whatwg] The <iframe> element and sandboxing ideas

A couple more thoughts.

1. When seamless is set, the compatMode of the iframe should be the same as
that of the parent browsing context, even if the doctype of the iframe would
put it in a different compatmode than its parent. 2. The corrollary to this
is that when seamless is not set that the compatMode of iframes created from
JS should be backcompat unless a doctype is document.write'ed in. This is
what every browser does currently AFAIK.
3. The behavior of seamless in the face of different overflow values needs
to be spec'ed as well. I think the current spec deals well with
overflow:visible. But if overflow is scroll or auto, then it should behave
the way a div does with overflow scroll or auto (i.e. not size it's height
to its contents).

Ojan

On Sat, May 24, 2008 at 10:55 AM, Ojan Vafai <ojan.vafai@gmail.com> wrote:

> On Wed, May 21, 2008 at 3:30 PM, Ian Hickson <ian@hixie.ch> wrote:
>
>>  * I've added a seamless="" boolean attribute to <iframe>, which, if
>>   the content's active document's URI has the same origin as the
>>   container, causes the iframe to size vertically to the bounding box
>>   of the contents, and horizontally to the width of the container,
>>   and which causes the initial containing block of the contents to be
>>   treated as zero height. In addition, styles on the root element of
>>   the content must inherit from the <iframe> instead of being the
>>   initial values, and the style sheets that apply to the <iframe>
>>   must also apply to the contents. In addition, any time the browsing
>>   context navigates itself, the parent browsing context gets
>>   navigated instead.
>>
>
> This looks awesome.
>
> So, the whole point of these is defining elements that are isolated from
> their surrounding context on different axes. Same origin iframes currently
> just give you CSS isolation. sandbox affords script isolation. seamless
> affords the ability to turn off the CSS isolation.
>
> Seems to me that we need a third property which controls event isolation.
> Currently events don't propagate in/out of iframes and event coordinates are
> all relative to the iframe's viewport (e.g. on mouse events).
>
> My first intuition was that seamless should also just propagate events and
> have mouse coordinate be relative to the parent browsing context. But I can
> think of cases where you would want to control the two separately. For
> example, if you are especially concerned about performance and don't want
> events in the parent browsing context to be handled by the iframe's
> contents.
>
> Ojan
>