W3C home > Mailing lists > Public > www-style@w3.org > February 1997

Re: Wrong approach towards Frames (was: New tags...)

From: Stephanos Piperoglou <spip@hol.gr>
Date: Tue, 11 Feb 1997 17:55:57 +0200 (EET)
To: Jim Wise <jw250@columbia.edu>
cc: Dave Carter <dxc@ast.cam.ac.uk>, Subir Grewal <subir@crl.com>, HTML Discussion List <www-html@w3.org>, www-style@w3.org
Message-ID: <Pine.LNX.3.95.970211163935.206A-100000@fenchurch>
[ I'm Cc'ing this to www-style because it refers to StyleSheets and their
use to solve the frame problem ]

On Tue, 11 Feb 1997, Jim Wise wrote:

> > <BANNER>
> > was a superior implementation of what frames are mainly used for, now
> > sadly dropped. But my main complaint is that the biggest advance of all
> But I don't think <BANNER> or <FRAME> are very well thought out.

WHY on Earth does ANYBODY think <BANNER> isn't well thought out, or to put
it another way, that it's not a good solution?

Take a look at any site using frames today. They are used for VERY specific
purposes: Creating "navigation bars" (i.e. top-level ToCs) and presenting
logos, copuright notices etc. That is, frames are simply a part of the
document that doesn't scroll. Nobody uses them for anything else!

What's the main drawback of Netscape's implementation? Each frame contains a
seperate document, hence a link can only be followed in one frame at a time.
What do people do to counter this? They use platform- and browser-dependant
scripting languages to change more than one frame at a time (i.e. to make
the "Next" button point to the next section or the icon representing the
document you're viewing be highlighted). But ALL frame-enabled pages revolve
around one main frame where the document is displayed, which usually
scrolls, and one or more "supporting" frames which display static

Netscape's structure is based on the philosophy that many equivalent
documents are displayed simultaneously. That's the problem with this
solution, and a CSS-based solution that was proposed a while back by Bos,
Raggett and Lie called "Frame-based layout via Style Sheets" [1]. It
approaches the problem from the wrong angle.

[1] http://www.w3.org/WWW/TR/NOTE-layout.html

<BANNER> puts all frames in ONE document. This is good because frames are
really just "satellites" around the main document, thus they update with
every new document, and they can be displayed inline if the user agent
doesn't know about BANNER. This does not really waste any appreciable
bandwidth, it only takes less time and effort for the document author to get
the desired result.

Granted, BANNER is very poorly defined in the HTML 3.0 draft [2], but
essentially it just defines a non-scrolling region of the document. Ring any
bells? This is clearly a presentational attribute (using the word
"attribute" in its general - i.e. not HTML-specific - sense here). All
authors want to do is take a portion of their document and put it in an area
of the screen (not canvas) so that it's seperate and doesn't scroll.

[2] http://www.w3.org/pub/WWW/MarkUp/html3/banners.html

Now the CSS Layout proposal ([1] above) got this right, only it had to jump
in and include the "content" property to include other documents, and then
propose targets for anchors a-la Netscape. This makes the whole thing break
down. ONE document, MANY frames, and if a link is followed then the new
document may redefine new frames or have the same ones, as it wishes,
without causing any nesting or update problems.

I think NOTE-layout should be revised, with "content" and all the stuff
about the TARGET attribute to <A> removed, and with the "Layout Politics"
and several other sections changed to reflect the existence of the recent
"Positioning HTML Elements with Cascading Style Sheets" draft [3], and
perhaps made a Working Draft to be considered for inclusion in CSS2, but
that's W3C politics and mechanisms which I have little to do with.

[3] http://www.w3.org/WWW/TR/WD-positioning

  Stephanos Piperoglou aka Sneakabout - http://users.hol.gr/~spip/index.html
  All I need in my life is a little love and a lot of money. In that order.

                                               ...oof porothika! (tm)
Received on Tuesday, 11 February 1997 10:57:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:42 UTC