Re: Frames spec & the NOFRAMES tag

Stephanos Piperoglou wrote:
> I'll repeat my mantra against frames (it's been repeated again and again on
> this list...). I think that 99.99% of current applications of frames would
> be greatly simplified if you could simply define the content of frames
> within a document, in something like <div style="frame: top">content</div>.
[...]
> I've said this time and again both here and on www-style, I still don't
> understand why nobody implemented frames like this.

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.

Basically, one of the main reasons frames were developed was to allow
changing the content viewed in one frame while keeping the content in
the others the same, for more flexible navigation and presentation of
multiple documents on a web site, and this is exactly why they were
designed to use different URLs for the individual frames.

I'm not defending the current implementation of frames, mind you, but I
do think that there are a large number of uses for frames currently
being employed which would have real problems under your model.

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:

  <LINK REV="frameset" HREF="http://www.foo.org/myframeset.html"
   TARGET="document_frame">

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.

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.

I must say, I am relieved to see that HTML 4.0 seems to have gotten rid
of the horribly silly (and annoying) restriction against using anchor
references in FRAME URLs.

-alex

Received on Wednesday, 4 March 1998 19:14:09 UTC