LISTSERV mailing list manager LISTSERV 15.5

Help for HTML-WG Archives

HTML-WG Archives

HTML-WG Archives


Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font


Join or Leave HTML-WG
Reply | Post New Message
Search Archives

Subject: INSERT draft comments (was RE: HTML 3 suggestion)
From: Brian Behlendorf <[log in to unmask]>
Date:Wed, 24 Jan 1996 22:51:44 -0800 (PST)

TEXT/PLAIN (80 lines)

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

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/

Back to: Top of Message | Previous Page | Main HTML-WG Page



CataList Email List Search Powered by the LISTSERV Email List Manager