- From: lilley <lilley@afsmail.cern.ch>
- Date: Wed, 20 Sep 1995 15:14:18 +0100 (BST)
- To: alexed@netscape.com (Alex Edelstein)
- Cc: html-wg@oclc.org, www-html@www0.cern.ch, marca@neon.netscape.com, ebina@neon.netscape.com, daver@neon.netscape.com
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 | +-------------------------------------------------------------------+
Received on Wednesday, 20 September 1995 10:16:39 UTC