RE: OBJECT vs IFRAME (was RE: Hyperlinks in OBJECT inclusions)

> -----Original Message-----
> From: John T. Whelan [mailto:whelan@physics.utah.edu]
> Sent: Thursday, August 20, 1998 9:32 PM
> To: www-html@w3.org
> Cc: braden@endoframe.com; liam@htmlhelp.com
> Subject: OBJECT vs IFRAME (was RE: Hyperlinks in OBJECT inclusions)
>
>
> [analogy between frames and HTML OBJECTs deleted]
>
> >> Where inclusion.html is as before.  The behaviors of the two
> >> alternatives are not the same, since the frame-replacement behavior
> >> cannot be achieved by browsers that see the non-frame
> option.  IMHO,
> >> the same should go for the HTML OBJECT.
>
> >Certainly this is appropriate for IFRAME. But wasn't part of
> the reason for
> >including both IFRAME and OBJECT to provide mechanisms both
> with and without
> >this degree of subordination? Put a different way: if this (what you
> >describe) is the behavior you want, why not use IFRAME?
>
> >Braden
>
> To quote the Web Design Group
> <http://www.htmlhelp.com/reference/html40/special/iframe.html>:
>
>   OBJECT is more widely supported than IFRAME, and, unlike IFRAME,
>   OBJECT is included in HTML 4.0 Strict.

Well, that quote does not hold true in the context we're talking about.
AFAIK, IE4 (and, presumably, the IE5 beta) is the only browser to support
HTML inclusions via OBJECT, while both IE3 and IE4 support IFRAME. So in
this context, IFRAME is better supported. In fact, the only browser that
does support HTML inclusions doesn't work the way you're advocating (and
IFRAME does!). None of what we are discussing here is sufficiently broadly
supported to be used in any but the most specialized applications, so I
don't see how support issues are at all relevant.

Even if we discount all that is left ambiguous about OBJECT, these elements
have distinctly different behavior: OBJECT cannot be targetted; IFRAME can.
So the two are *not* interchangable.

> Now, I was under the impression that IFRAME, like APPLET, had been
> deprecated in favor of OBJECT, and this was reinforced by the WDG's
> description of IFRAME, to wit "IFRAME provides a subset of the
> functionality of OBJECT".

While true, that's not a very good thing to say, because it's ripe for
misinterpretation. While IFRAME may provide a subset of OBJECT's behavior,
IFRAME also does something(s?) OBJECT can't, so it isn't accurate that
OBJECT provides a superset of IFRAME's functionality.

>  But now that I look at the actual HTML4.0
> spec, with phrases like "Authors may use either the IFRAME element or
> the OBJECT element for this purpose, but the elements differ in some
> ways"
> <http://www.w3.org/TR/REC-html40/struct/objects.html#embedded-
> documents>,
> I realize that IFRAME may have been omitted from HTML 4.0 Strict for
> the same reason the TARGET attribute was (not that that strikes me as
> a very good reason, but that's another thread).
> 	That aside, is it useful to *have* a separate IFRAME element
> with behavior distinct from OBJECT TYPE="text/html"?  It seems like
> with a useful set of conventions for the meanings of TARGETS on links
> inside and outside the frame, all of the functionality could be built
> into OBJECT.  In the long run, OBJECT TYPE="img/whatever" should
> replace IMG, but it's not useful to start ditching IMG yet because
> it's in such widespread use and recognized by all browsers.  OTOH,
> IFRAME is about as new as OBJECT, so why bother building up the
> infrastructure for IFRAME so it can someday be deprecated?

If this discussion goes the way of extending OBJECT to be a complete
superset of IFRAME's functionality, I would totally agree with you. But it
has been my impression that there was a deliberate decision to give them
separate behaviors. As such, I think having resources linked from included
documents replace the host document when called is in keeping with this
separation.

I think we would agree that if TARGET were resurrected, and OBJECT's
behavior extended as you describe, we could dispense with FRAMESET, FRAME,
and IFRAME. While I believe that would be desirable, it does not seem to me
to be the direction the HTML 4 spec has taken.

Braden

Received on Thursday, 20 August 1998 23:09:38 UTC