- From: Albert Lunde <albert-lunde@nwu.edu>
- Date: Sat, 29 Nov 1997 21:09:14 CST
- To: knoblock@worldnet.att.net
- Cc: davidp@earthlink.net, www-style@w3.org, www-html@w3.org
> >If you want an included HTML document to function as part of the main
> >document, it will have to inherit the style state at the position of the
> >OBJECT in the parent document's tree. There could be some strange side
>
> I'm looking at it from a practical viewpoint, looking to avoid hacks like
> frames and finicky server side includes. I'd be happy to see some other way
> to better accomplish the same thing than using OBJECT if needed.
>
> >content. Note also that you will be nesting HTML and BODY elements. What
>
> Does the document have to be a full HTML document? Could the included
> document be an HTML fragment, as with SSI now?
When the IETF html-wg was working on the HTML 2.0 spec, requests
for some sort of include feature were raised repeatedly, but not
put into the spec. I think this exclusion was not accidental, but
is rather based on (1) the difficulty of vaildating a document
containing includes (2) difficulties in expressing what people
want in an SGML framework. (There are also some SGML features
that might serve some of these purposes but which aren't
implemented in "tag soup" browsers.)
Server-Side Includes work because they are kept on the server side:
the client doesn't have to deal with them, and they are clearly
layered outside the HTML/SGML parsing and display process.
<OBJECT> was intended to work as a generalization of a whole
bunch of take-something-and-stick-it-in-the-middle-of-a-document
tags like <IMG> <APPLET> and others, but it wasn't intended
to be a #include sort of a thing.
Inconsistent and non-orthogonal implementations seem to be
crippling the use of <OBJECT>.
--
Albert Lunde Albert-Lunde@nwu.edu
Received on Saturday, 29 November 1997 22:09:49 UTC