Re: Inline text/html

On Sat, 7 Sep 1996, Arnoud Galactus Engelfriet wrote:

> > > I would have to re-read the working draft on OBJECT[1], but I don't
> > > see why "text/html" would not be a possible media type for inlined
> > > data.
> 
> The idea was that you can do what server-side includes allow you to
> do: include arbitrary texts into an HTML document. This would allow
> for caching on the client (no need to re-generate the document with
> the toolbar, and no need to send that 4K for the toolbar again), and
> the server doesn't have to do as much work to calculate the length
> of the data to send.

This was sort of what I was interested in looking at.

(Unfortunately my ISP is having problems and I can only get out as far as 
my ISP at the moment, so all URL references to 'Object' are currently 
useless to me. At the time the book I had (which only covers HTML 3.0) 
had FIG, and that was why I was asking about FIG.)

This could also be useful for a sort of 'windowed' text view as well, 
allowing you to display a window with text in it, allowing the browser to 
provide abilities like scrolling, saving, printing, searching, and so on.

> There are some drawbacks, though.
> 
>   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. It's default background 
would be the current background of the 'previous' HTML file. This could 
allow infinite nesting (well, it'd be a bugger, but not unmanagable.

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

>   3. What media type should the inlined HTML get? It can't be text/html
>   since it (in most cases) cannot be a valid HTML document by itself
>   if it wants to be inlined.

Using a nested document, it could. It can also be treated as a seperate 
document, which means that current browsers could just load the pages if 
necessary.

> And those are just the ones that I can come up with. :-)

There's also the problem of older browers, but having them as 
self-contained html files means that they can just be loaded, using 
either anchor tags thru-out the main html file (to specifically load the 
pages, which could be good in any case), or using a whole seperate HTML 
file, specifically for those browsers.

With this sort of implementation, you could cater for non-frames aware 
browers within the NOFRAMES tags, (allowing the specific frames to become 
inline documents), or even with a little meddling and additions, make it 
a frame based system. (Each inline document could be specificed as a 
floating window, or part of a frame).

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.

Using an existing tag for this however could be messy (lots of lesser 
options to define). However you could always specify that both the 
'long' and 'short' ways of defining it are valid, which ensures that 
whichever way it's defined, it will be accepted.

/--------------------------------------------------------------------------\
| Stuart Young (aka Cefiar)  - You may be human, but you're still animals! |
| nakor@glasswings.com.au - If you've done 6 impossible things, write HTML |
\--------------------------------------------------------------------------/

Received on Sunday, 8 September 1996 06:42:57 UTC