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

Revising a comment I made yesterday. A couple other things came to mind.
What happens if an iframe is loaded with sandbox set and then the property
it is unset? What security origin is it in? Similiarly, what happens when
seamless is set/removed on an iframe already in the page? Does it start
inheriting CSS and resize to fit it's content? I don't feel strongly about
what should happen in these cases, seems worth being explicit though.

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

I thought about this some more and this seems like a bad idea. If you
actualy link to a page that expects to be quirks from a standards parent,
then this could be break things. I'll modify this to the following:

Iframes with an empty src (or no src property) should inherit their parent's
compatmode iff seamless is set, otherwise they should be in backcompat
unless a standards doctype is document.write'ed in.

Again the latter part of that is for compatibility with current browsers.


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