Re: A proposal for addition to HTML 3.0: Frames

From:	lilley <lilley@afs.mcc.ac.uk>
Date:	Wed, 20 Sep 95 10:35:52 EDT
Alex Edelstein copied this Internet Draft to html-wg:

> A Proposed Extension to HTML: Frames

This seems to be a new aggregating document type which gives compound
document layout and synchronisation features for multiple HTML documents
or other media types.  I like it.

I thank Netcape Corp. for sharing this Internet Draft with this group,
even before the first draft has been posted to the Internet Drafts
editor (at least, it has not shown up on my local mirror).  It is
nicely documented, although there is no DTD fragment as yet so it is not
clear how well it would integrate with the rest of the HTML DTD; this
aspect seems to have received the least attention.  As I shall show,
this is not a problem.


Having read through the proposal in detail, I think the overall
functionality proposed is very useful for integrated tools which combine
many functions.  I also note that the proposed functionality will be
integrated into the forthcoming Netscape Navigator 2.0 which will allow
real-world experience to be gained with the proposal.

I have some detailed comments and suggested modifications, which I hope
Eric Bina and Alex Edelstein will give consideration to.  In view of the
imminent release of the beta of 2.0 I have taken care to restrict
changes to those whose implementation should be little trouble for
the fine programmers at Netscape Corp.


> A Frame Document has a basic structure very much like your normal
> HTML document, except the BODY container is replaced by a FRAMESET 
> container which describes the sub-HTML documents, or Frames, that 
> will make up the page.

> <HTML>
> <HEAD></HEAD>
> <FRAMESET></FRAMESET>
> </HTML>

So all that is actually inherited from HTML is the contents of HEAD -
title, and other metainformation.  Most of an HTML document is contained
in the BODY, and this is not allowed in a Frame Document.


> <FRAMESET>
> This is the main container for a Frame. It has 2 attributes ROWS
> and COLS. A frame document has no BODY, and no tags that would
> normally be placed in the BODY can appear before the FRAMESET 
> tag,or the FRAMESET will be ignored. The FRAMESET tag has a 
> matching end tag, and within the FRAMESET you can only have other 
> nested FRAMESET tags, FRAME tags, or the NOFRAMES tag.

I would suggest that it would be much cleaner to declare Frame Documents
as a new SGML document type, distinct from HTML.  I suspect there would
be no problem in principle with lifting the definition of HEAD from the
HTML 2.0 specification.  (Dan?  Is that correct?  I believe this came up
before with CML)

Advantages:

- Agility of deployment and development, independent of the HTML
  standardisation process which, as recently noted, is taking longer
  than planned.
  
- Small, easily implemented specification
  
- Clean separation of functionality; it is doing a different job to HTML

- Backwards compatibility; clients that do not understand text/frame-doc
  need not try to parse it.  Existing clients would otherwise possibly
  be confused by the unknown tags.

- The NOFRAMES tag, which seems to allow HTML BODY content, can be
  dropped as there would be alternative means of providing this
  functionality (see below).  However, I do appreciate the thought behind
  providing this tag for backwards compatibility.

Deployment

If Frame Documents were served up as a distinct media type, what should
be done with other clients that do not yet support this new type?  (Same
problem as what to do with existing clients that do not support Frames
as an HTML extension). Two possibilities present themselves:

a) Content negotiation

Accept: text/frame-doc

If there is a frame-doc it is sent; smart servers might send a text/html 
alternative.

b) Multipart/alternative - see RFC 1521

Noting that Netscape 1.1N already accepts multipart MIME types (see for
example http://alpha.mic.dundee.ac.uk/cgi-bin/ufo which has

>  Content-type: multipart/x-mixed-replace;boundary=ThisRandomString

then a Frame Document could be sent with an alternative HTML document as
follows.  Note that in accordance with RFC 1521 section 7.2.3 the most
faithful alternative is given last.


+------------------- sample HTTP session ----------
| HTTP/1.0 200 OK
| Date: Wednesday, 20-Sep-95 13:12:33 GMT
| Server: NCSA/1.3
| MIME-version: 1.0
| Content-type: multipart/alternative;boundary="=_ThisRandomString"
|
| --=_ThisRandomString
| Content-type: text/html
| ... suitable HTML document goes here ...
| --=_ThisRandomString
| Content-type: text/frame-doc
| <DOCTYPE FRAMEDOC PUBLIC "-//IETF//DTD FRAMEDOC//EN">
| <FRAMEDOC>
| <HEAD><TITLE>An Example</TITLE></HEAD>
| <FRAMESET COLS="50%,50%">
|  <FRAMESET ROWS="50%,50%">
|    <FRAME SRC="cell.html">
|    <FRAME SRC="cell.html">
|  </FRAMESET>
|  <FRAMESET ROWS="33%,33%,33%">
|    <FRAME SRC="cell.html">
|    <FRAME SRC="cell.html">
|    <FRAME SRC="cell.html">
|  </FRAMESET>
| </FRAMESET>
| </FRAMEDOC>
| --=_ThisRandomString--

(This example includes some tags which could probably be omitted, but
not having a DTD for the Frames proposal I just put them all in).

As Netscape Navigator does not currently seem to make much use of Accept
types, this second solution seems to be the easiest for Netscape to
implement, as it re-uses existing code.

In a later message, Alex Edelstein said:

> Note:  We are holding off on submitting officially to the RFC Editor
> until we can work up some adequate DTD ATTLIST and ELEMENT
> definitions.  Actually, we're looking around a bit for DTD experts...

If any of the SGML gurus on this WG would like to rustle up a DTD for
this new document type, which includes the HTML HEAD element plus the
FRAMESET and FRAME elements, I am sure that the authors of the Frames
ID would be pleased to include it before it goes off to the ID editor.
Because this need not include the bulk of the HTML DTD this should be
quite a small job for someone suitably qualified.


-- 
Chris Lilley, Technical Author
+-------------------------------------------------------------------+
|       Manchester and North HPC Training & Education Centre        |
+-------------------------------------------------------------------+
| Computer Graphics Unit,             Email: Chris.Lilley@mcc.ac.uk |
| Manchester Computing Centre,        Voice: +44 161 275 6045       |
| Oxford Road, Manchester, UK.          Fax: +44 161 275 6040       |
| M13 9PL                            BioMOO: ChrisL                 |
|     URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html       | 
+-------------------------------------------------------------------+
Follow-ups

Bert Bos (bert@let.rug.nl)
Daniel W. Connolly (connolly@beach.w3.org)