Followup-To: comp.infosystems.www.authoring.html
In-reply-to: jrg@blodwen.demon.co.uk's message of 22 Feb 1996 01:10:59 +0000
Newsgroups:
alt.hypertext,comp.infosystems.www.authoring.html,comp.lang.python,comp.lang.perl.tk
Subject: A Criticism of NS Frames [was: Strongly-Typed Hyperlinks]
References: <31164A18.25C4@passage.com> <4f6onv$t18@Venus.mcs.com>
<4fvei0$fnr@Mercury.mcs.com> <4gf0qv$4v9@wapping.ecs.soton.ac.uk>
From: connolly@w3.org (Dan Connolly)
Date: 24 Feb 1996 11:52:57 -0500
Message-ID:
Organization: W3C
Lines: 319
- --text follows this line--
In article jrg@blodwen.demon.co.uk (James R
Grinter) writes:
> In article <4gf0qv$4v9@wapping.ecs.soton.ac.uk> gjh@ecs.soton.ac.uk (Gary Hill) writes:
> > I'd also be interested to hear your reasoning for why one wouldn't
> > want to link to definitions. We have an application which is used by
> > first year biology students, which has an online dictionary, and
> > that proved very popular with users. Again, I can see why such links
> > don't work so well in the context of the
>
>
> I imagine that's one way in which Netscape envisage their 'frames'
> concept being used, allowing you to control what the browser displays:
> you could have a lower window in which the footnotes or glossary terms
> appear.
I would very much like to use NS Frames for this purpose. For example,
I'd like to write a frames description for browsing the HTML 2.0 spec
which put the table of contents along the left column,
footnotes/glossary/references at the bottom, and body text in the
majority of the reading window.
In anticipation of such user agent features, in producing the HTML
version of the HTML 2.0 spec (from a LaTeX-like SGML representation) I
included link relationships like SUBDOCUMENT, FOOTNOTE, and GLOSSARY:
In:
http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html
you'll see:
Scope
and in:
http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_1.html#SEC1.1
you'll see:
(oops! these should have been rel/rev duals, e.g. rev=toc in the
html-spec_toc.html document. Anyway...)
You'll also see:
(see section HTML DTD).
(1)
HTML Document
Type[MIME]
Unfortunately, I can't exploit these link relationships using Netscape
Frames. Worse yet, in order to get the effect I want, I have to
construct the "user interface" that I'm interested in, and add
target=... markup to my document to match that user interface.
It's not, in general, possible for the consumer of the information, or
a third party, to construct a different user interface -- or view --
of the information based on the same markup.
I suggest that the target=... mechanism is presentation-specific
markup, just like and . It gets the job done in some
cases, but it's unncecessarily inflexible, and discourages information
providers from doing The Right Thing.
Consider an alternative decription of frames with rules that map link
relatinoships to target frames. (I'm using Tk pack semantics, and
expressed in Tcl for clarity, though I'd prefer an s-expression
notation if I were writing a GUI editor for these things):
# reading window
frame .read
# TOC frame on the left
frame .read.toc -width 15%
pack -left -fill y .read.toc # umm... I'm not sure about
# the -left syntax
# Footnote frame at the bottom
frame .read.foot -height 20%
pack -bottom -fill x .read.foot
# body window for the rest
frame .read.body
pack -fill both .read.body
# start by reading the TOC into the TOC window
load .read.toc html-spec_toc.html
# links in TOC frame with rel=subdocument go to the body frame
# and vice versa
.read.toc linkrel subdocument target .read.body
.read.body linkrel toc target .read.toc
# links in body frame with rel={glossary,footnote,bibliography}
# go to the foot frame
.read.body linkrel bibliography target .read.foot
.read.body linkrel footnote target .read.foot
.read.body linkrel bibliography target .read.foot
# This is the default. Don't need to write it:
# .read.body linkrel xref target .read.body
The syntax doesn't matter, except that I want to be clear that this
is _not_ the text/html media type: it's application/x-frames or some such.
I'd like to see this sort of feature in Grail, HotJava, or any of the
other VHLL-hackable web browsers out there (e.g. scheme, perl5, tcl
...). If you're interested in hacking on this idea, please send a note
to www-talk@w3.org.
This idea is not new. The thread started in Aug 95:
Date: Sun, 20 Aug 95 03:31:19 EDT
Message-Id: <3036E492.2781@mozilla.com>
From: Lou Montulli
To: Multiple recipients of list
Subject: Generalizing Banners
From: "Daniel W. Connolly"
Subject: Re: Generalizing Banners
To: montulli@mozilla.com
cc: Multiple recipients of list
Date: Sun, 20 Aug 1995 09:33:39 EDT
The frames extention was then proposed in its present form:
To: Multiple recipients of list
From: Alex Edelstein
Date: Tue, 19 Sep 1995 02:08:00 EDT
Subject: A proposal for addition to HTML 3.0: Frames
Message-Id: <305E5CF5.45AE@netscape.com>
Here are my original comments in full:
From: "Daniel W. Connolly"
Subject: Re: Generalizing Banners
To: montulli@mozilla.com
cc: Multiple recipients of list
Date: Sun, 20 Aug 1995 09:33:39 EDT
In message <3036E492.2781@mozilla.com>, Lou Montulli writes:
>Currently in the HTML 3 draft is a great new tag called BANNER
>that allows the document author to embed another HTML document within the
>current document.
Err... that's already a more general interpretation of the BANNER
element than I have seen. The BANNER element can't contain a whole
HTML document; for example, it can't have its own title. See below
for details.
>Combined with forms and the interactive nature of the Web this can be a very
>expressive user interface. Espescially if the banners can load
>independently of each other and can effect the contents of the others.
>
>But I think that BANNERs need to be generalized beyond the simple
>concept for which they are named. It is more desireable to
>divide the window up into arbitrary configurations rather than
>just horizontally.
I like the idea you're presenting, but I wouldn't associate it with
the BANNER element at all -- you're talking about compound documents
in general, I think.
>With this expressive power it would be possible to emulate almost
>any existing user interface. Using form elements links and
>images (server or client side) and a method for having one cell
>effect changes in other cells you could design new UI's
>that are specifically suited to the web application your are
>trying to develop.
Danger! You're getting into the domain of user interface description
languages like Motif's UIL, or Tcl/Tk, or DEC/SRC's Trestle. If you
want to describe user interfaces, I suggest you use one of those. In
fact, I hear the folks working on AT&T's online service have some sort
of "dialog description language" that they're pretty happy with. I
suspect AOL has something similar. Safe-Tcl is pretty available too...
>My question to this group is what would be the best
>syntactical way to add this expressive power to HTML?
Good question. And as usual, my minimalist answer is: this
functionality doesn't require any changes to HTML at all. To make a
comound document, I think you should aggregate simple documents,
similar to the way HTML and GIFs are agregated, rather than making
HTML more complex.
>Consider a window like this:
>
>|------|------------| **layout1
>| | |
>| | |
>| Doc1 | Doc2 |
>| | |
>| | |
>|------|------------|
>
>Or
>
>|------|------------| **layout2
>| Doc 1 |
>|------|------------|
>| Doc2 | Doc3 |
>| | |
>| | |
>|------|------------|
Those look familiar. I've seen windows like that in browsers like
Panorama, HaL's OLIAS, Booklink's browser, etc. -- all using plain old
HTML 2.0.
But in those systems, the windows got into that configuration at
the request of the reader, not the author. I suppose that's the
wrinkle you're trying to introduce.
Of course there's a trade-off: what sort of expressive capability can
we give to authors without presuming too much about the clients
capabilities or the reader's preferences?
For example, allowing authors to say "make one window 640x200 pixels,
and place the other 1/2 inch below..." would lead to interoperability
problems, not to mention problems in media other than large bitmapped
displays. And not to mention users getting pissed off that some
information provider has presumed to take over the whole display.
Even expressive capability along the lines of "use the top 1/3rd of
the window for this, and split the bottom 2/3rds among six equally-
sized windows" is going to cause problems on, for example, palm-top
devices.
One way to go is to make pixel and screen geometry specifications
expressible, but to acknowledge that they'll be ignored in
circumstances where taking them litterally would make no sense. But
pixel and screen geometry shouldn't be the only idioms.
The idioms should express more general constraints: "Whenever you
display doc X, also keep doc Y visible/navigable." Look at
the 
markup as shorthand for:
alt
That hints at how link relationships can be used to build window
configurations as above. To achieve layout2, I'd
use a combination of link relationships and stylesheets, ala:
You could ship the documents across the wire in separate HTTP
transactions (possibly in the same TCP connection, using HTTP
extensions), or in one HTTP transaction using a copound document
format like multipart/mixed, or even tar.
Another possibility is that doc1 is not the "root" document:
the "root" document could be a safe-Tcl analagous to the
stylesheet above.
As much as I dislike Tcl for its lack of "programming in the large"
support, I think it's the most mature and available technology to
enhance web user interfaces. Java, Visual Basic, and python come
to mind immediately as competitors. There are others. See:
http://www.w3.org/hypertext/WWW/MobileCode/
What I'm saying is that to achieve more powerful user interfaces,
HTML isn't necessarily the only tool or even the best tool.
This is the sort of thing I was hoping to see in a "Forms and
Interactive Documents" draft, or perhaps in a "Link Relationships"
draft.
About BANNER:
The HTML 3.0 draft's description leaves a lot to be desired, but
here it is for reference:
HTML 3.0: Banners
http://www.w3.org/hypertext/WWW/MarkUp/html3/banners.html
Fri Mar 24 16:05:01 1995
|Banners
|
|Permitted Context: the start of the BODY element
|Content Model: %Body.Content
|
|The BANNER element is used for corporate logos, navigation aids,
|disclaimers and other information which shouldn't be scrolled with the
|rest of the document. It provides an alternative to using the
|LINKelement in the document head to reference an externally defined
|banner.
That description gives usage examples, but doesn't actually specify
anything :-{
Anyway: my interpretation of BANNER is that it's intended to capture
the existing idiom where folks put a row of buttons at the top/bottom
of a document, and they'd prefer that those buttons didn't scroll
away.
>If you use multiple banners you could have documents like this:
[...]
The HTML 3.0 draft specifies 0 or 1 banners.