frames: why they must be destroyed

This is long; I apologize.

> Some sites have complicated parts, largely static (e.g. the navigation
> bars). It drives me nuts when they slowly rebuild the whole page every
> time because they don't use frames, and if they waste too much of my
> time I leave. Is there another way or ways of keeping part of the page
> unrefreshed that does not use frames? If not, what's wrong with frames?
> We are saving our readers' time.

With slow connections this is a problem.  I have a 28.8k line at home.
I'd rather have the page load slowly than use frames, though.

- Why are frames bad?

I can't bookmark a framed page; the bookmark won't work right.  I can't look
at the URL bar of a framed page and see where I am.  I can't send the URL to
a friend; he will see something different.  The frames don't stay in sync,
especially if I use the Back button.  Framesets look bad in small windows.
Search engines have problems with frameset documents, too.

Worse, frames break the Reload button.  If I click Reload, I lose my place.
My browser reloads the frameset, and all the pages displayed in the frames
revert to the defaults.  There is no way to go back to where I was.  Utter
frustration.

Frames don't save much network traffic.  If anything, they cause more
requests to be sent and slow down the initial display.

I don't think these are particularly ivory-tower objections, either; they're
real reasons frames suck.  I see frames less often now than in the early
days.  I think that means people agree.


- Should frames be removed from HTML?

Sure.  It doesn't hurt HTML 4 users to drop features, since most HTML 4
documents are incompatible with XHTML 1.0 in 80 different ways already--
nothing to do with frames.

Language design is a matter of taste.  If we find a feature is
complex, and implementations vary, and other specs have competing
features that are as complete and better or easier or less error-prone,
then maybe we should drop the old feature.

Frames have problems.  If a better feature is in another spec, frames
should be dropped.


- Won't this prevent XHTML from killing Tag Soup?

As browsers improve, authoring tools are freer to use HTML
features properly and not worry about how it will look under
Netscape 3.  Better authoring tools will kill Tag Soup.

In my opinion, good authoring tools will have to avoid frames
anyway.  To build good sites, the authoring tools will make
authors focus on content.  Frames won't be an issue.

Little sites will still use frames.  They'll still be ugly and
have usability penalties ten years from now.  It'll be more
obvious, though.

XHTML will become a suitable language for building big web
sites faster, more stably, with more collaboration and better
use of your employees.  That's (part of) the future, and that
is why Tag Soup will fade away (though it will never completely
die).


- So what's the better feature that will replace frames?

In other words, once frames are gone, how can developers duplicate
the "good" uses of frames?

Frames are best used for navigation.  Sometimes they are also used
to provide different views of data, or related data (e.g. the
three-pane view of a mailbox and folders.)  And sometimes, they are
used to stick a common header or footer on every page, or make sure
it is always in view.  Sometimes frames are used just to make
part of a page scroll.

XSLT and CSS can do most of these things.  Navigation, disclaimers,
footers and so forth can be pasted in with XSLT.  This will conserve
bandwidth better than frames, once the browsers catch up.  To make
part of a document scroll, use the 'overflow' property of CSS2.
Separate panels with different views of data can be done with
server-side or client-side scripting (client-side DOM would be quite
good for this.)

Navigation, in general, needs a closer look and better supporting
features.  But that's another topic.

-- 
Jason Orendorff

Received on Tuesday, 18 January 2000 16:42:56 UTC