Re: Keeping HTML Simple & Format negotiation between Browser & Server
Jonathan Abbey (broccol@csdsun1a.arlut.utexas.edu)
Thu, 27 May 93 14:24:29 CDT
Linda Murphy (murphy@dccs.upenn.edu) wrote:
| Subject: Keeping HTML Simple & Format negotiation between Browser & Server
| Date: Thu, 27 May 93 09:46:03 -0400
| From: murphy@dccs.upenn.edu
|
| There's been a discussion on www-talk about how complex HTML should
| become -- and the building opinion seems to be: keep HTML simple, and
| allow more complicated formats to be embedded "in-line" in the HTML,
| and negotiated between the server and the client.
|
| [...]
|
| Problems with this model:
|
| 1) If the browser starts up another application to handle a portion of
| the document in a foreign format, what happens if that item in the
| document was SUPPOSED to be in-line with other portions of the
| document? How does the browser pull it back into the display of
| the document and make it part of the whole?
The Macintosh and Microsoft Windows systems are moving toward compound
document architectures, as is X11R6. This shouldn't be an
insurmountable problem.
With X, one could look at an imbedded object, try to determine its
appropriate size, then ask a renderer to image a file into a
sub-window inside the browser's viewing area.
|
|
| 2) What if one wants to put hot-spots (links) into one of these
| foreign format objects? For example, suppose one wants the user to
| be able to point & client on a portion of the mathematical formula,
| which is linked to another mathematical formula (or a graph, or a
| piece of text, etc) which more fully explains it?
|
This is the biggest argument for always providing a canonical image
representation of non-plain-textual data.
My dream for ultimate flexibility in the browser would be for the
server and the browser be able to negotiate the browser's needs for a
canonical, viewable image of the document.
1) The browser would ask what size the image (or paper, or whatever)
is designed to be viewed at.
2) The server would report the designated image size, along with a
summary of its capacity for generating other image sizes.
3) The browser would request an image of whatever parameters best suit the
available display.
4) The server would either
- Image the document according to the browser's specifications,
caching it for future retrieval by browser's with similar needs.
or
- Send the one image closest to the browser's requirements for that
document if no dynamic image generation were possible
Each link in the image would consist of:
- a union of rectangles designating the boundary of the link
- a URL
- a set of flags, perhaps including one indicating whether the link
should be decorated by the browser, or whether the link is already
decorated in the image
5) The browser would scale the image if necessary (obviously it would
be preferable for the server to be able to generate an image that
is best suited for the browser, but if not the browser would scale
the image and the corresponding regions down), then present it to
the user.
This way, links could be provided in a reliable fashion within ANY
kind of complex data, and exterior viewers could be used to do a
better job of imaging a particular kind of data to other output
devices at the browser's disposal. E.g., a PostScript document would
be available on screen at an appropriate resolution with links
included, and the same document (or a version of the document that
didn't have the links decorated) could be sent to a file or a printer.
It might even be possible to provide the same set of links with
something that is imaged at the browser's side if there is a
definitive representation for that data type that can be relied on.
Something similar could be done with sound files by
providing a start and stop time for a particular link. Video files
likewise, with start, stop and a union of rectangles.
--
Jonathan Abbey
broccol@csdsun1a.arlut.utexas.edu
Applied Research Laboratories
The University of Texas at Austin