Re: A proposal for addition to HTML 3.0: Frames

From: Joe English <joe@trystero.art.com>
Date: Mon, 25 Sep 95 13:37:43 EDT


------- Forwarded Message
From:           Joe English <joe@trystero.art.com>
Date:           Fri, 22 Sep 1995 14:49:57 -0700
To:             lilley <lilley@afs.mcc.ac.uk>
Subject:        Re: A proposal for addition to HTML 3.0: Frames 


> > FRAMES documents are (or at least can be made to be)
> > compatible with level 2 browsers; the <NOFRAMES> element
> 
> requires that the new document type includes the whole 
> HTML 2.0 body content for the NOFRAMES element, or (worse) 
> has to track HTML 2.x as it evolves.

That actually isn't as difficult as it sounds; check out the DTD
and other stuff at

    <URL:http://www.art.com/~joe/frames/index.html>

This defines a new "wrapper" DTD for "-//Netscape//DTD HTML with Frames//EN"
that includes HTML 2.0 by reference.  


> > Labelling FRAMES documents as something other than 'text/html' [*]
> > would defeat this entirely.
> 
> No. As I showed several days ago, wrapping these up as a 
> multipart/alternative is a workable solution *now* . Did 
> you catch that posting, Joe?

Yes; I think multipart/alternative will be a very useful way
to go in the long run.  Unfortunately today's browsers don't
understand enough MIME to make it work properly.
(Lynx and NCSA Mosaic 2.6 both punt and save to disk
when they see a multipart/alternative message, for example). 

Today's browsers would also do the wrong thing with this scheme:

    <XXX><ALT>...</ALT>real XXX here</XXX>

but in the special case where <XXX> has no text
content of its own (<FRAMESET> and <EMBED>/<FIG>), 
it should work OK.

I don't think we've seen the last of the new extensions, either...
Format negotiation is going to get hairier and hairier
the more extensions there are, and I think part of the
problem can (and should) be addressed at the SGML level.


--Joe English

  joe@art.com