Re: Body start tag.

Stephanos Piperoglou (
Sun, 20 Jul 1997 14:31:30 +0300 (EET DST)

Date: Sun, 20 Jul 1997 14:31:30 +0300 (EET DST)
From: Stephanos Piperoglou <>
To: Paul Prescod <>
cc: Joe English <>,
Subject: Re: Body start tag.
In-Reply-To: <>
Message-ID: <>

On Wed, 16 Jul 1997, Paul Prescod wrote:

> That was my idea when I first saw frames. They are really a very
> different "document type" than your typical HTML document. This is why
> we are running into these implied start tag problems. Any "real" HTML
> document has a single required BODY, so it is convenient to leave off
> the tags. I have no precise definition for what is a "real" document but
> any document class that requires radical changes to the HTML DTD and
> where instances of the class use a radically different mix of elements
> and attributes should probably be a "different" document type with its
> own different, but related DTD. We might find that letting the two
> evolve separately will allow some innovations in FRAMES that would have
> been difficult as part of HTML.

Oh yes indeed! This is a beautiful suggestion, but it might need some

Each HTML document (under the CURRENT spec) has a header which contains a
TITLE, LINKs and META information, amongst a few other things. But if it is
a frameset, these apply to all documents in the frameset, while the
corresponding information in each document is lost in current

Personally, all I'd need is an implementation akin to HTML 3.0's BANNER
element. The only thing frames are useful for is providing navigational
tools and company logos. If I could take a chunk of my document and simply
put it in a non-scrolling region somewhere on the screen, I'd be happy (and
backwards-compatible, too). Frame-based layout via Style Sheets [1] does
this just fine. I was amazed it was never made a working draft.


I think that if the content property is removed from NOTE-layout, then it
would make a simple, clear, and backwards-compatible frames implementation.
The content property for me is simply a hack to make it look like the
FRAMESET implementation... I think multiple documents on screen is something
for the user to do with multiple browser windows, NOT for the author to
decide. Making an HTML document that does not make sense if it's not shown
together with other documents is bad practise and doesn't make sense. HTML
documents should be complete. One of the most important drawbacks of the
FRAMESET implementation is that it is impossible to reference a specific
state of the frameset using a resource + fragment identifier URL; only the
initial state can be referenced, making the implementation unsuitable for
large documents.

Specific advantages:

- You don'y have to worry about targets; all of what you see on screen is
ONE document.

- You can't get the "mixed-up frames from hell" phenomenon simply because
the author forgot a TARGET attribute.

- Frames are a clearly presenatational issue; you can seperate them from
your HTML

- Every single HTML document is now a complete document. You don't need CGI
hacks to reference a specific state of a frameset. You can reference a
document at a specific point in it and the frames will draw themselves
around it.

- You do *NOT* have to provide alternate versions of a document via the
NOFRAMES element! This is probably the most important advantage of all...

- There is no ambiguity concerning the information in the header of an HTML
document, since there is only one header for the whole document and not one
for each frame.

    Stephanos "Pippis" Piperoglou -
All I wanted in my life was a little love and a lot of money. In that order.
                [ Failure is a crime. Defeat; an atrocity! ]

                                                   ...oof porothika