Re: A proposal for addition to HTML 3.0: Frames

Chris Lilley writes:
 |Bert Bos says:
 |
 |> I've been thinking about multi-pane layouts for document for some
 |> time, so I was very interested to see Netscape's proposal for
 |> frames. Unfortunately, it fell short of my expectations. The frames
 |> solve part of a problem, while making it harder to solve the rest.
 |
 |I see frames, not as *a* multi-pane document but as an aggregating 
 |mechanism for compound documents or other media. This also seems to 
 |be how the Netscape proposal sees them.

Probably, but HTML itself is also a vehicle for compound documents,
see the LINK, IMG and FIG elements, plus Sun's APPLET and similar
experiments.

 |> 2. Frames don't allow content in the same document in which the frames
 |> are being defined. This extra indirection is often unneeded and makes
 |> maintenance harder.
 |
 |Which is why I suggested a new document type might be appropriate. If all 
 |the body content is disallowed, most of HTML has been removed anyway.
 |
 |What did you think of my proposal, Bert?

It's better, but not optimal. It's better to define the frames in a
document with a different media type, than to try to squeeze them into
HTML. It certainly makes it easier to create software. And it also
avoids the thorny issue of updating the HTML DTD.

Still, I'm not convinced that expressing the layout in a style sheet
isn't a better method. At least the effects of link traversal
(Netscape's TARGET) have to be in a style sheet somewhere, because
they certainly don't belong in HTML. Indeed, they *cannot* even be
encoded in the document itself, because the same document could be
displayed in different contexts and its links could behave differently
based on that.

And also, the `text/frame-doc' type, as you suggested, is delightfully
simple, but probably too simple. What exactly is its purpose? Netscape
may be happy with a document type that can express nothing more than
simple tabular layouts of documents in a window, but I'm not. I've
tried to describe some ideas how to make it more flexible. (I've got
more, but I wanted to keep the message short.)

(Now I wonder: after seeing the `text/frame-doc' suggestion endorsed,
or at least not immediately dismissed by some well-known names on this
mailing list, do the inventors at Netscape perhaps regret having
suggested an SGML-based format, instead of immediately going for a new
media type with a non-SGML format?)

 |> 6. The frames offer no obvious way for extension of the syntax, to
 |> allow other kinds of layout, such as paged or non-visual layouts.
 |
 |True.  However, the point of aggregation is enhanced ergonomic visual 
 |display. For speech output, sequential "display" of the component 
 |documents is probably a better bet.

On the whole, I would rather turn things round: instead of embedding
documents in a style, I would like the style to be *applied* to a
document. That way the document is the main interface, *its* URL is
displayed, and I can apply different styles to it, including ones for
a low resolution display, high-resloution hard-copy, or a speech
synthesiser.

Transclusion of documents (through FIG and SGML entities) is a
separate issue and shouldn't be mixed with layout.



Bert
-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN