RE: Hyperlinks in OBJECT inclusions

> -----Original Message-----
> From: Jukka Korpela [mailto:jkorpela@cc.hut.fi]
> Sent: Thursday, August 20, 1998 3:22 AM
> To: braden@endoframe.com
> Cc: W3C HTML Mailing List (E-mail)
> Subject: Re: Hyperlinks in OBJECT inclusions
>
>
> On Thu, 20 Aug 1998, Braden N. McDaniel wrote:
>
> > Consider the following:
> [ an HTML document which does OBJECT inclusion of another
>   HTML document, with the following error: ]
>
> > 	<OBJECT DATA="inclusion.html" TYPE="text.html" WIDTH="320"
>
> It should be "text/html", not "text.html".

Of course... I spent about 11 hours of today driving, so something like this
was bound to happen.<g>

> Interestingly,
> (my copy of) IE 4.0 seems to treat the situation so that the
> object cannot be included, i.e. displays the content of the
> OBJECT element instead. Whether this is correct behavior or not
> depends on the interpretation of the nature of the TYPE attribute,
> which has been discussed at length.

And unfortunately never resolved in the specification, AFAICT.

> > When I click on the link in the inclusion, what does the
> new resource
> > replace? The entire host document (and inclusion), or just
> the inclusion?
>
> A good question. Do I guess right when I assume you have noticed
> what IE 4.0 does (namely the former), and you are wondering whether
> such behavior is correct? More exactly, we can ask whether it is
> a) _the_ correct behavior, b) _a_ correct behavior (among different
> possibilities allowed by the spec), or c) incorrect behavior.

Actually, I'm less interested in learning whether IE4 is "correct" or not
than I am in learning the *desired* behavior in this situation. I'm also
interested in whether this behavior is deemed a property of OBJECT itself,
or a property of the data type being included (consider formats other than
HTML which may include hyperlinks).

> Let us first formulate a question at the
> presentation-independent level:
> Assume document A contains an OBJECT element which refers,
> via the DATA
> attribute, to an HTML document B, which contains a link (say,
> via A HREF)
> to a document C. Is that link from A to C or from B to C?
>
> Obviously, from B to C.

I think it's less than obvious; I think you have omitted a possibility in
your consideration: is it a link from A to C *and* from B to C? I think the
notion of B as an inclusion--that is, B is *part of* A--suggests that this
is in fact the case.

And this, IMO, is one of the things that separates OBJECT from IFRAME. With
IFRAME, I think there seems to be a notion that a frame's contents are
discrete documents. OBJECT strikes me as a more seamless and closely
integrated means of composition.

> It's difficult to find any reason to think
> otherwise, especially with regard to the following:
> "An embedded document is entirely independent of the document
> in which it
> is embedded. For instance, relative URIs within the embedded document
> resolve according to the base URI of the embedded document,
> not that of
> the main document. An embedded document is only rendered
> within another
> document (e.g., in a subwindow); it remains otherwise independent."
> ( http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.5 )

Some, IMO, *awfully* vague language for reasons that have been discussed at
length pretty recently here.

> But one may still ask whether it is an acceptable _implementation of
> links_ that when a link in an embedded document is followed, the
> target document replaces the entire current content (the embedding
> document).

IMO, this is the preferable implementation. But it raises some questions
that have even less clear answers. For instance, what if the inclusion is a
frameset?

> The specifications mandate no particular implementation of links.

How this is implemented could cause content to behave drastically
differently (read: break) depending on the implementation. It needs to be
specified.

> For instance, when a normal link is followed on a graphic browser,
> the target document might be presented in the same window, in
> another existing window on the screen, in a new window, or in another
> screen.

Going back to a previous question: what if the host document *and* the
inclusion are framesets, and one of their frames coincidentally shares the
same name?

> Thus, my answer is that IE 4.0 behavior is b) _a_ correct behavior,
> as far as the specifications are considered. And similarly,
> my answer to
> the general question you asked is that both behaviors are within the
> (vague) semantics defined in the specifications.

I agree. And I think that is a problem.

> Which one is _better_, pragmatically? Hard to say. The dimensions
> of the display area for the embedded document, whether set by the
> WIDTH and HEIGHT attributes, or by a style sheet, or selected
> by the browser, might be suitable for the embedded document but
> unsuitable for a document it links to. Thus, although my first
> intuitive reaction was to say it's more natural to display it in
> that area (replacing just the embedded document), I'm not sure of it.
> I wouldn't even say that the specification should be amended to
> make a _recommendation_ or even a description of "typical
> implementation".

Why not? Don't you think this would dramatically affect the way certain
content works? This is not simply an implementation detail. It's an integral
feature of how the *browser platform* works. And aren't these standards
about creating a uniform browser platform for interoperability?

> _If_ some recommendation were given, it could say that a browser
> should, if possible, let the user follow links in such cases in
> different ways, at least in the ways presented in the question
> and so that the document is opened in a new window (if possible).

I do not think a "recommendation" is adequate (though perhaps one would
suffice as a short-term solution).

Braden

Received on Thursday, 20 August 1998 04:12:36 UTC