HTML4.0 draft: comments re: inclusion of frames

[I previously sent this article to the list editor, but have received no
feedback from anybody]


I am very disappointed and alarmed at the inclusion of Netscape's 'frame'
construct within the draft HTML4.0 specification.


I wish to express, in the strongest terms, my concern that frames should not
be allowed to enter the rulebook of standard HTML.


As I am sure you are well aware, a great number of web-readers have a strong
dislike of frames, and I have to admit to including myself in this group. I
do not feel that the use of frames should be 'officially' encouraged.


*   The very nature of frames is such that frames do not fit well into the
concept of HTML as a device and presentation independent standard.

While it may be useful for authors to incorporate independently
scrolling, permanently 'visible' navigation bars, similar to those proposed
in the BANNER element of the obsolete HTML3.0, at present, many websites
which incorporate frames do so in a very reader-unfriendly manner, and in
particular, force the layout preferences of the *author* onto the reader,
which is completely against the aims of HTML.


It is still common for frames not to be correctly handled on a large
number of browser clients, particularly Lynx and its audio and braille
browser descendents for readers with vision impairments.
In fact, it is only within the past few months that frame-aware browsers
have become available on my platform of choice.

*   Many web authors point blank *refuse* to incorporate meaningful
<NOFRAMES> data in their documents, other than the sarcastic and deprecating
"Get Netscape" comment (Netscape is not available for my platform/OS, and is
of no use to blind web-readers, etc).

This existing scenario does not lead me to believe that web authors will
adequately cater for readers who are either unable to view framed pages, or
who do not wish the clutter of frames on their screen, in the future, and
this alone should be reason to reject frames as currently used.


In particular, it is common for site authors to over-use frames, which
results in the following problems for readers:

*   'Framed' pages take *considerably* longer to load as it is necessary for
the browser to make two or more connections and retrieve two or more
documents before the document can be read. This is a major concern for users
of the web who are connected via dial-up modem links, especially in the
cases where call charges are applied and therefore increased online time
results in greater personal expense.

*   Frames affect the layout of the browser window in a negative way, taking
considerable amounts of window space, particularly where scrollbars are
necessary.

Most webusers have deliberately set up their browser clients in line with
their own preferences, and resent being forced to alter the settings, such
as expanding browser windows, etc.

For example, in my case, I prefer to have 2 tall and narrow browser windows
open on screen adjacent to each other. When I encounter a framed site, I
unfortunately have to enlarge a window, partially obscuring the other window
in order to have a usable readable area visible.


When there are two or more frames on a page, the usable window area is
*dramatically reduced*. This can make web-browsing particularly unpleasant 
and difficult where the reader prefers a smaller window size, has a smaller
screen resolution, or uses a text-based client such as Lynx.

*   All too often, web-authors use frames to replace conventional browsing,
rather than as an extra downwards-compatible embellishment. In other words,
it is not possible to read or *navigate* a site unless you are able to view
frames and are compelled to use them, adding to window clutter.



I must object to the proposed inclusion of frames, and instead would propose
a revision to the now obsolete HTML3.0 BANNER element in their place:

*   Allow the inclusion of *one* (or at most two) independently scrolling
    _navigation bars_ per page, (to serve a purpose similar to the most
    common frame use)

*   The navigation bars would appear in 'standard' positions relative to the
    main document (eg above or below the main text, or even to the left or
    right of the main text in columnar form), the position to be defined by
    the *reader* in their browser client configuration, thus retaining some
    user control over the layout of their browser window.

*   In addition, with this simpler layout proposal, it should be much easier
    to incorporate these navigation bars into text-based browsers such as
    Lynx, where they could simply appear at either the top or bottom of the
    current page of text. This should also resolve the problem of browsers
    being unable to correctly handle this type of information.

    Page loading time should also be reduced, as with only vertical or
    only horizontal alignment of banners, the client would not need to
    perform such complicated page formatting as is required for the often
    'matrix-like' arrangement of frames favoured by some authors.

--
David Marsh, drmarsh@bigfoot.com                                         //
Glasgow/Glaschu, Scotland.  *If urgent, please phone: 0141 636-6084.*  \X/ix
> CYCLEWAY: cycle activism UK/IE: http://squelch.home.ml.org/cycleway/ <

Received on Thursday, 21 August 1997 18:23:26 UTC