- From: Stephanos Piperoglou <spip@hol.gr>
- Date: Sun, 20 Jul 1997 14:31:30 +0300 (EET DST)
- To: Paul Prescod <papresco@technologist.com>
- cc: Joe English <joe@trystero.art.com>, www-html@w3.org
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 thought: 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 implementations. 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. [1] http://www.w3.org/pub/WWW/TR/NOTE-layout 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 - http://users.hol.gr/~spip/index.html 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
Received on Sunday, 20 July 1997 07:33:09 UTC