Re: <iframe doc="">

> >>> The question still remains... would @doc allow SVG code, for 
> >>> example?

Travelling down this road of trying to allow something else than 
native html to be specified as content for <iframe> is being bit by 
trantula. I can see, for example, including any html file, even one 
that contains an img or <object> or <embed>, but to allow anything 
else than html for the source turns the dance into solving the same 
problems as for <object> and <embed> in that there are other things 
that need to be specified, like type=mime, for instance, and defining 
processes and interfaces with iframe that connect to the plugin.
I take sandbox to mean that if I, as the author, specify that an 
iframe element is to be sandboxed, then whatever goes into that 
element has very limited communication with the host DOM.
Can I specify that host DOM scripts cannot exchange events with the 
iframe context?
Can I specify that the iframe context does not have access to the host 
DOM?

When the iframe contains just html - no plugin context - then I should 
be able to define if events initiated in the iframe are propagated 
into the containing document and vice-versa. Even if the html contains 
a plugin it is still fairly easy to control access in/out of the 
plugin and the DOM that contains the iframe.
However, I think allowing iframe to directly specify content that 
requires a plugin is heading for problems. Define that <iframe> only 
includes native html (which might include code that specifies content 
that requires a plugin), then allow me to specify how the iframed 
content can interact with the host DOM.
Only .html or .xhtml src documents, please.

Besides, this sandbox topic with respect to plugins needs to be 
developed further for <embed> and <object>.

Thanks and Best Regards,
Joe



----- Original Message ----- 
From: "Leif Halvard Silli" <xn--mlform-iua@xn--mlform-iua.no>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Doug Schepers" <schepers@w3.org>; "Tab Atkins Jr." 
<jackalmage@gmail.com>; "Leonard Rosenthol" <lrosenth@adobe.com>; "Ian 
Hickson" <ian@hixie.ch>; <public-html@w3.org>
Sent: Thursday, January 14, 2010 12:43 PM
Subject: Re: <iframe doc="">


> Maciej Stachowiak, Wed, 13 Jan 2010 12:52:20 -0800:
>>
>> On Jan 13, 2010, at 12:50 PM, Doug Schepers wrote:
>>
>>> Hi, folks-
>>>
>>> Tab Atkins Jr. wrote (on 1/13/10 10:23 AM):
>>>> On Wed, Jan 13, 2010 at 8:42 AM, Leonard
>>>> Rosenthol<lrosenth@adobe.com>  wrote:
>>>>> I don't understand how you can assume that the destination of 
>>>>> the
>>>>> doc URL is going to be text/HTML?  Why couldn't the iFrame be
>>>>> pointing to an SVG image, for example, or a PDF?  Those are also
>>>>> valid (and in the latter case of PDF, quite common) things one
>>>>> would put in an iFrame and wish to refer to...
>>>>
>>>> @doc doesn't take a url, it takes literal html code (with quotes
>>>> escaped).  It is intended to help with the use of 
>>>> multiple<iframe>s
>>>> on a page, especially @sandbox'd ones, so that you don't incur
>>>> multiple network requests but still get the security benefits of
>>>> framing the content such as blog comments.
>>>
>>> The question still remains... would @doc allow SVG code, for 
>>> example?
>>
>> Using SVG-in-HTML, yes (since it assumes a text/html MIME type).
>> Using the traditional XML serialization of SVG, no.
>
> And if I serve the HTML5 document as application/xhtml+xml, then 
> what?
> Would @doc then still expect text/html - only?
> -- 
> leif halvard silli
>

Received on Thursday, 14 January 2010 21:25:00 UTC