Re: Generalizing Banners

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 <IMG alt="alt" src="image"> markup as shorthand for:

	<a href="image" rel="embed present">alt</a>

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:

	<style notation="x-dans-tcl-ish">
	set frame1 [frame [this-doc]]
	set frame2 [frame [linked-doc [elt -withid DOC2]]]
	set frame3 [frame [linked-doc [elt -withid DOC3]]]
	pack $frame1 -top $frame2 -left $frame3
	</style>

	<a href="Doc2" rel="present" id="DOC2">
	<a href="Doc2" rel="present" id="DOC3">

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.

Follow-ups

• Brian Behlendorf (brian@organic.com)