Re: Non-Scrolling Region

David C. Martin (dcmartin@library.ucsf.edu)
Wed, 28 Sep 1994 13:49:41 PDT


We have used the ROLE attribute and made it the browser's responsibility
to provide the GUI elements for navigational control. In addition, we
are experimenting with the Dienst notion of multiple content types to
have links associated with the printable form, the appropriate search
and help pages, etc...

I really think the format question should be solved through the server's
response in what formats are available and that printing, searching and
help should be integrated back into the base browser for control (i.e.
when you go to print the document in postscript, download the postscript
version of the document, don't convert. Same applies for the help menu
bar item and the search functionality.

dcm

---
Assistant Director			mail: dcmartin@ckm.ucsf.edu
UCSF Library & Ctr for Knowledge Mgt	at&t: 415/476-6111
530 Parnassus Avenue, Box 0840		 fax: 415/476-4653
San Francisco, California 94143		page: 415/719-4846
--------
Dave Raggett writes:

Ralph Graw writes:

> Has anyone given any thought to the idea of a "non-scrolling" region > defined by HTML+ tags? This seems analogous to a capability within help > file systems such as that in MS Windows. It could be used for tool bars, > a bit of context for long material, etc. They could expand horizontally > as the window is resized, have a .GIF for a background, be located/aligned > similar to images, etc. There could be multiple defined, allowing the > folks at <a href="galaxy.einet.net">Galaxy, for example</a>, to put their > imagemap bars where they probably wanted them originally.

Funny you should mention that, but I am just in the process of experimenting with this for the HTML 3.0 proposal.

In HTML+ I extended the LINK element and defined a fixed set of REL attribute values for this purpose. Using LINK in this way to define navigation buttons (or menu items) makes it particularly easy to add hypertext paths or guided tours where a separate list of URLs is used to insert Previous and Next buttons into the toolbar. In fact the HTTP protocol even defines a mechanism for using WWW-Link: fields in the MIME header that are merged into the document head. This gives us a way of defining toolbars for other document types than HTML.

The basic requirements are:

o Defining a set of buttons or menu items that can be viewed on graphical and non-graphical browsers, preferably with the ability to provide a custom graphic

o Providing a way for automatically inserting Previous and Next buttons when following a guided tour

o Static text such as "Company Confidential"

o Static images such as corporate logos

In my opinion the position of the non-scrolling area should be a matter of personal preference, e.g. whether you prefer it to be at the top, left or right sides, or the bottom of the scrolling area. The security status of a document *shouldn't* be part of either area to avoid the worry that authors might work a way of fooling the user with a suitably chosen graphic. SecureMosaic uses a new region placed next to the globe device.

Anyway, I hope to get something working, but am running out of time for WWWF'94. The email load is getting in the way of programming :(

--
Best wishes,

Dave Raggett

----------------------------------------------------------------------------- Hewlett Packard Laboratories email: dsr@hplb.hpl.hp.com Filton Road tel: +44 272 228046 Stoke Gifford fax: +44 272 228003 Bristol BS12 6QZ United Kingdom