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

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

	But the possibilities in targeting OBJECTs extend beyond
text/html and replacing frame-type functionality.  Imagine this
combination

<A HREF="two.jpg" TARGET="viewer">Make the image change.</A>
<OBJECT NAME="viewer" TYPE="img/jpeg" DATA="one.jpg" HEIGHT=100
WIDTH=100>If you're reading this, you're probably not going to enjoy
the demonstration.</OBJECT>

Image substitution without client-side scripting!

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

	As evidenced by the fact that I misinterpreted it! :-)

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

[...]

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

	Well, IFRAME would be a lot easier to replace than FRAME and
FRAMESET.  The latter would seem to require extensions to CSS and much
better implementation thereof (as mentioned on www-style).

> While I believe that would be desirable, it does not seem to me
>to be the direction the HTML 4 spec has taken.

	Judging only by the spec itself, I have very little idea what
the W3C philosophy on the future of frames is.  Almost every feature
which is in HTML 4.0 Transitional but not HTML 4.0 Strict is
"deprecated", meaning it's on the way out and should or will be
replaced by "better" features.  However, TARGET doesn't fall into that
category.  FRAME and FRAMESET also do not appear in HTML 4.0 Strict,
but that's because frameset documents have their own DTD.  (Was that
really neccessary, BTW?)  The HTML documents appearing inside frames
have to be either Strict or Transitional, and most *should* be
Transitional so they can set TARGET="_top" for links to external
sites.  So what happens when the "transition" is over?  Frames,
annoying though they can be, are not going to go away, and so TARGET
will have to be part of the reunified DTD.

	I suppose if they're trying to keep frames ostracized, keeping
OBJECT from having frame-like behavior and instead maintaining IFRAME
as a second-class citizen is the way to do it.  But the people who are
going to abuse frame structures are not likely to care what the W3C
says anyway.

	The argument against having a subwindow that can be targeted
with changing content is that it's not possible to bookmark the state
of a structure like that.  That's true, and it's one of the annoyances
about frames--I ended up writing a CGI to create a frameset on the fly
so I could reference many different frame states without having to
build a static frameset document for each--but the same can also be
said for an HTML form which has been partially filled out, or a page
whose appearance has changed due to client-side event handlers.

					John T. Whelan
					whelan@iname.com
					http://www.slack.net/~whelan/

Received on Friday, 21 August 1998 01:32:05 UTC