[5908] in www-talk@info.cern.ch
Re: Non-Scrolling Region
daemon@ATHENA.MIT.EDU (David C. Martin)
Thu Sep 29 01:28:13 1994
Date: Thu, 29 Sep 1994 06:24:43 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: dcmartin@library.ucsf.edu
From: dcmartin@library.ucsf.edu (David C. Martin)
To: Multiple recipients of list <www-talk@www0.cern.ch>
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
