- From: Terje Norderhaug <Norderhaug.CHI@xerox.com>
- Date: Mon, 26 Jun 1995 15:13:01 -0800
- To: jw@scitsc.wlv.ac.uk (Jon Wallis), www-html@www10.w3.org
At 10:52 PM 6/25/95, Jon Wallis wrote: >>At 02:29a 06/25/95, Philippe-Andre Prindeville wrote: >> >>>Just here: image scaling (ie. fitting an image into a >>>640x400 rectangle), depth reduction (taking a 24bit GIF file >>>and rendering it in 1bit deep B&W on a notebook), etc. should >>>be done *SERVER-SIDE*. >I think most of the action *should* be server-side (i.e., only send what the >browser wants or can handle), but this requires a start-up dialog between >browser and server to establish what the browser *can* handle (not too >difficult to establish). It is already partly in place, as the browser will send what formats it support. >Also there seems to be too much emphasis on >"in-line" capabilities - the fact that you can spawn "helper-apps" was/is a >real strength of Web browsers - extensibility and preservation of original >media types being just two benefits In-line capabilities is very important, and should be even more emphasized. However, whether to display the inlined information in the document, display it in in a spearate window, or leave it as a link should be the decision of the browser/user, and not the author. A helper app could be able to display a media type within any document displayed by a browser, and is supported by the UI object mechanisms (OpenDoc, OLE, etc). Helper apps is more in accordance with modern software paradigms than having one fat browser that can do it all. -- Terje <Norderhaug.CHI@Xerox.com> <URL:http://www.ifi.uio.no/~terjen/>
Received on Monday, 26 June 1995 18:13:05 UTC