Re: <iframe doc="">

>> When you load HTML into an object/embed, what you get is exactly
>> the same as an iframe.

maybe so for some set of sameness. I think read the standard for the 
different elements.
If webkit is safari, then yes I can show a couple of examples that 
don't work. Not html but a test for a plugin look at:
http://www.hypermultimedia.com/x3d/URLTests/
is just an example of some simple test for a plugin maybe not quite 
ready to show and all example support files are not complete now. Tell 
me if you want to find out more.

The main idea in these examples is that a click in the plugin <object> 
element requests a new URL for either a new complete scene, or a 
sound, or a texture. In order for this to work the plugin has to be 
able to to run its own script engine and request a url from somewhere 
and the host has to cooperate.

One testing step would be to instead create a simple html file with an 
anchor in it and see if the <iframe>, <embed>, and <object> allow me 
to replace the contained document. And also figure out how the host 
DOM can affect the nested DOM.

> If you put text/html into an <object> element (which is what we're 
> suggesting with @doc), then it acts just like a frame.

An iframe is not a frame. and iframe is not an object. Maybe for html 
content the functionality could be similar but there is a very narrow 
band where an object should act like an iframe unless the iframe does 
actually represent a separate browser instance. Otherwise that seems 
only slightly nutty to me. Including @doc in <object> is even more 
over the edge and totally bordering on I don't know what.
.
> In WebKit, HTMLObjectElement, which represents the <object> element, 
> is a subclass of HTMLFrameOwnerElement, which represents all the 
> frame-like elements (e.g., <frame>, <iframe>).

Now we also have <frame>? I need to see a picture of the hierarchy but 
I don't see much close connection between <iframe> and <object>. I do 
know that Safari is really the most far behind in figuring out what to 
do with plugins.

Thanks and Best Regards,
Joe



----- Original Message ----- 
From: "Adam Barth" <w3c@adambarth.com>
To: "Joe D Williams" <joedwil@earthlink.net>
Cc: "Henri Sivonen" <hsivonen@iki.fi>; <public-html@w3.org>
Sent: Monday, January 18, 2010 4:03 PM
Subject: Re: <iframe doc="">


On Mon, Jan 18, 2010 at 3:48 PM, Joe D Williams 
<joedwil@earthlink.net> wrote:
>> I don't understand why you think object/embed provides more 
>> security than
>> iframe. When you load HTML into an object/embed, what you get is 
>> exactly
>> the same as an iframe.
>
> Not in detail, I think you will find.
> I meant to say that <iframe> is for html while <object> and <embed> 
> are
> designed for plugins or other 'external' scriptable runtime like 
> flash or
> other live content. If you use <object> or <embed> I think you will 
> find
> events do not work the same as for <iframe>. For example if <iframe> 
> we try
> to limit access so that the 'nested' DOM acts like it is not 
> accessible from
> the host DOM. For <object> and <embed> that is not a simulation. The 
> context
> is actually different and events (should get) passed in an entirely
> different but familiar way.

Really?  Do you have test cases that demonstrate this difference?  In
WebKit, HTMLObjectElement, which represents the <object> element, is a
subclass of HTMLFrameOwnerElement, which represents all the frame-like
elements (e.g., <frame>, <iframe>).  If you put text/html into an
<object> element (which is what we're suggesting with @doc), then it
acts just like a frame.

Adam

Received on Tuesday, 19 January 2010 04:11:06 UTC