Re: No Frames element

Tim Bagot (tim@heaven.on.earth.li)
Mon, 23 Feb 1998 09:44:24 -0500 (EST)


Date: Mon, 23 Feb 1998 09:44:24 -0500 (EST)
From: Tim Bagot <tim@heaven.on.earth.li>
To: HTML mailing list <www-html@w3.org>
In-Reply-To: <f08882e2.34f1246f@aol.com>
Message-ID: <Pine.LNX.3.96.980223141502.13998A-100000@heaven.on.earth.li>
Subject: Re: No Frames element



On Mon, 23 Feb 1998 BDoelling@aol.com wrote:

> The <noframes> element should demonstrate functionality different from the
> <body> element, or else it should be eliminated as redundant. At present,
> there are three occasions where a <no frames> element would come into play:
> 
> 1. Browser does not support frames:
> 	In this instance, <no frames> should be ignored, behaving like a
> <body> tag.  To my knowledge, this is the current implementation in most
> browsers. 

Typically this does happen. Some browsers "know" that they do not support
frames and provide links to the frames. Obviously, this should be offered
as an alternative to NOFRAMES content, but is sometimes helpful when the
author isn't (e.g. simply using NOFRAMES as a container for instructions
to upgrade).

> 2. Browser supports frames, but frames are suppressed:
> 	Once more, <no frames> should function like a <body> tag. Once
> more, this is the common implementation. 

Same again really. I notice that Netscape still doesn't allow this.

> 3. Browser supports frames, frames are not suppressed:
> 	In this instance, <no frames> should not function as a <body>
> tag. Browser should suppress block information between the opening and
> closing <no frames> tags. Navigational information that is necessary for
> frame-suppressed (or frame-unable) browsing of the page may be included
> in the <no frames> block.  This is the sort of information that is often
> redundant in a frame-allowed page, as it is typically provided inside
> another frame. A frame-allowed browser should therefore suppress this
> infomration. This allows a single document to work in both a
> frame-allowed and a frame-unallowed environment, rather than requiring
> two complete sets of pages for a site. 

This is more or less what happens. If you are suggesting that it would be
nice to put LINK elements inside NOFRAMES, then I agree; if frames were
being designed from scratch then this would probably be the case (and
there would probably be much bigger differences as well). Unfortunately
we're stuck with what there is. Certainly, the NOFRAMES element is a
little redundant (sc. tautologous) in that it often contains a BODY
element which could do the same job just as well by itself. Once again,
there is little point in changing this at this stage, since support for
legacy documents would still be required, and people would be unwilling to
produce documents that might not be shown correctly by browsers expecting
to find <NOFRAMES>, or attempting to render both frames and a BODY element
not hidden inside NOFRAMES.

Now, of course, we can (or, at least, will soon be able to) use
stylesheets instead of frames. Since W3C has largely been ahead of the
implementors in this respect, the design has been more sensible, and it is
perfectly possible to write "framed" pages which will look reasonable on
browsers which do not support this - much better than having to duplicate
the entire content (as you do with frames).

Tim Bagot