Re: Inline text/html

Benjamin Franz (
Sun, 8 Sep 1996 13:39:24 -0700 (PDT)

Date: Sun, 8 Sep 1996 13:39:24 -0700 (PDT)
From: Benjamin Franz <>
To: Arnoud Galactus Engelfriet <>
Subject: Re: Inline text/html
In-Reply-To: <>
Message-ID: <>

On Sun, 8 Sep 1996, Arnoud Galactus Engelfriet wrote:

> In article <>,
> Stuart Young <> wrote:
> > On Sat, 7 Sep 1996, Arnoud Galactus Engelfriet wrote:
> > >   1. How do you restrict the contents of inlined HTML to something
> > >   that does not invalidate the document it is inlined into?
> > 
> > Well, you could either allow only 'specific' tags in an inlined HMTL 
> > file, which gets messy to regulate, or, treat it as a whole new document, 
> > nested as it were in the the current document. 
> A bit hard to formalize, IMO. Since HTML 3.2 allows you to set document
> colors, how can you prevent people from setting those in an "inline"
> document?

Why should you try to prevent it? I see no reason not to treat inlined
documents as opaque entities as far as the enclosing document is

> > >   2. How do you prevent things like opening tags in the main file
> > >   and the closing tags in the included file?
> > 
> > Using the nested file scenario, this could never happen.
> Agreed, but then you're doing something different. This would be
> like frames, with a separate document displayed inline like an image. 

Yup. Seems the rational way to do it.

> What I am talking to is inlining a la server-side includes. Then you insert
> pieces of text & HTML markup *in* the actual document you're sending.
> This would be very useful (no need to put a load on the server doing
> the processing, only having to cache that standard header & footer
> once...) but causes the problems I mention.

Ummm....Why not use inlined opaque documents plus REL and REV to specify 
semantic relationships between the footer/header and the main document?
This would avoid the 'but is it legitmate semantically' problem.

> > Note: there will have to be some way of differentiating between HTML and 
> > TEXT at the tag level though, as display of inline text with < and >'s in 
> > it could become a REAL problem for a browser that isn't aware that it's  
> > different.
> Having inline text a la GIFs would make this easy.. just draw a box
> of the appropriate size and render the text in that. The content-type
> should identify it as plain text, so the < and > should not get
> interpreted.

Sounds like a job for OBJECT to me.

Benjamin Franz