On Wed, 24 Jan 1996, Charlie Kindel (Exchange) wrote:
> There's nothing in the INSERT spec for adding HTML to the input stream of
> the parser (which is what I think Brian is really asking for).
Eh, not necessarily. I'd be happy to have them be separate documents,
separately rendered - if people want it inserted they can use an <ENTITY>
declaration at the top of the document and then insert that new entity in
the document, as SGML generally allows. Anyways, as separate documents
the separate bit gets rendered, its size requirements calculated, and
inserted just like the others, hopefully as seemlessly as possible in the
interface. The interface to "view source" could be interesting but
> That said,
> here's some thoughts on how INSERT could be used to sort-of get the same
> The only way INSERT would allow you to include HTML is as an "embedding".
> This will be super useful for "sidebars" that accompany a magazine article,
> for example. It can also be used to do something close to what Brian wants
> by having the embedding fill the entire width of the browser. You'd use
> INSERT like this to make it happen:
> <INSERT DATA="include.html" WIDTH=100%>
Yeah, that's what I would have imagtined it would have look liked. The
"WIDTH=100%" being redundant.
> If there is class code installed on the users machine that can be hosted via
> INSERT (e.g. an OLE Control or Java Applet) that maps to the .html media
> type, and that class code draws no border by default, and no background
> colors/bitmaps are used in either the containing or included document, then
> the contents of "include.html" will appear to be part of the containing
Right, and it could be recommended that presentational hints
(backgrounds, etc) be inherited from the containing document unless
specifically mentioned in the included document. And I'd presume any
browser which could render HTML in the first place could render an HTML
inline without too much hackery...
> One issue to think about here is what happens when the user clicks on a
> hyperlink within the included portion? How does the containing document
> "intercept" this navigation? Not sure how a Java Applet would be able to do
> this, but an OLE Control embedded in HTML will always ask it's container to
> do navigation.
Are you asking to what base a relative URL is compared in an included
document? I.e. if the included document had base "http://host/path1/file"
and the container had a base "http://host/path2/file", to which path would a
"foo.html" be referenced to? Tough one. I would presume it would be
relative to the included document. Compare this situation to an embedded
VRML file - if "http://host/path2/file" embeded
"http://host/path1/file.wrl" and "file.wrl" had WWWInline calls to
"object.wrl", I would expect it to be relative there. Do any of the
inline-VRML viewers deal with this situation otherwise?
Unless you mean something else...
> There are other problems with this: what happens if the user selects text
> above the inserted text and drags down... He'll select some text, then the
> embedding, then more text... Probably not what he meant.
I'd say apply the same rules as if a selection was made spanning an
embedded image - does that image get copied to the clipboard as well?
[log in to unmask] [log in to unmask] http://www.[hyperreal,organic].com/