W3C home > Mailing lists > Public > www-html@w3.org > March 1998

Re: Frames spec & the NOFRAMES tag

From: Stephanos Piperoglou <sp249@cam.ac.uk>
Date: Fri, 6 Mar 1998 16:43:29 +0000 (GMT)
To: Alex Stewart <riche@crl.com>
cc: www-html@w3.org
Message-ID: <Pine.LNX.3.96.980306162521.203B-100000@teatime.joh.cam.ac.uk>
On Wed, 4 Mar 1998, Alex Stewart wrote:

> Go take a look around Netscape's developer web site for (just a couple
> of many) examples, then.  With your scheme, the entire contents of the
> developer site there would have to be contained in ONE single web
> document.  Not only would that be horrendous to maintain, but anyone
> visiting the site would have to spend an eternity downloading content
> they're not interested in just to view the couple of sections they do
> want.

I think you've misunderstood what I proposed completely. However, I don't
think we should discuss this again, I had this discussion with the list when
NOTE-layout ("Frame-based layout via Style Sheets") [1] was first published.
You can check the archive for the details.

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

> As for the issue of jumping into the middle of frame-based systems,
> particularly with search engines and such, I do agree that this is
> something of a problem.  What I would suggest, however, is a new LINK
> type or something equivalent which would allow a frame-content document
> to specify where its frameset document is located:

This issue has been rehashed again and again, and proposals from new
elements to extensions like yours to new URL schemes have been proposed on
the list, all of them with basic problems. How would you express a
four-frame frameset in which 3 of the four (or all four) of the frames have
been changed to new contents? And look at it semantically: Is what you're
viewing one document, or many documents? If it's one document, then that
makes it one big document, and most people don't want big documents, as you
pointed out. If it's many documents, than current implementations, like
DevEdge Online, which you mentioned, and I use very often, have problems.

Problems with DevEdge Online, which is a typical example of frame use:

It reloads the frameset ALL the time. Otherwise it would be impossible to
bookmark/link to anything but the root document, and the TITLE of what
you're viewing would always be "DevEdge Online"

It's impossible to link to a specific section, let alone use a fragment
identifier to link to a tail link somewhere within a document that's
displayed in one of the frames.

While you're viewing the site, there's ALWAYS a "main" frame and the rest of
the frames are just "supporting" frames. The "main" frame contains the
actual document you're viewing, while the "supporting" frames contain
information about navigation, document titles, etc. This is VERY bad,
because it means that neither the documents in the "supporting" frames nor
the document in the "main" frame CAN STAND ON THEIR OWN. They are, in an
abstract way - not the strict SGML view of the thing, invalid. Essentially,
you have the document(s) in the main frame that SHOULD contain the
navigational info. The frames are merely a presentational issue. You could
have the same exact document structure without frames, the only difference
is that the content of the "supporting" frames would be contained in the
"main" frame. This is the logical way to do it.

> Frames-capable browsers which recognized this LINK type could
> automatically fetch the frameset document, render all of the frames, and
> then render the original URL inside the frame specified by the TARGET. 
> Thus, even if you jumped to a frame-content document, it would appear
> the same as if you had navigated there inside the frames context.

see above.

> For that matter, a <LINK REL="noframes" ...> link type could specify a
> document to fetch instead of the current document if the user's browser
> is configured not to display frames.  With these two LINK types defined
> and used in on a web site, a user could switch back and forth between a
> frames version and a non-frames version using only their browser
> settings (instead of depending on (often clumsy) buttons and links on
> the web site to do it), the whole time keeping their place seamlessly
> within the context of the web site.

What you propose would have to be A LOT more complicated in order to work as
you propose. And a lot of problems would still exist.

-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All I want is a little love and a lot of money. In that order.
------------------------- http://www.thor.cam.ac.uk/~sp249/ --
Received on Friday, 6 March 1998 11:45:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:20:33 UTC