- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 21 Mar 95 19:43:44 PST
- To: Siegmann P <paul@cs.vu.nl>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Why it is needed: It often happens that someone wants to view http://www.foo.bar/obnoxiouslylongdocument.html, or wants to view a document of a shorter size, but has a very slow connection. What usually happens is that the person accessing the document reads the first screenful of text, and bases his decision to wait for the rest of the document, or to break the transfer all together on that first screenfull. So the writer of a long html-document, or a document with a lot of images has to make the first screenfull attractive enough in order to have his entire document read. This is in sharp contrast with the idea of structured documents. My proposed solution to this problem is the following: Order the different parts of the document according to their relative importance, with the use of the proposed <LP> tag. This tag lowers the priority of the enclosed block, and can be nested, to lower the priority of some parts of the document even more. I think you have identified an important problem, but I'm not so happy with your proposed solution. Other people have already pointed out some of the flaws. I'd like to propose a different approach. This also may not be such a good idea, so if other people don't like it, I'm not going to push it too hard. Suppose, as you did, that the author of the HTML file expects some users will want to view parts of the document before the whole file is transmitted. Instead of marking certain parts with priorities that control the order in which they are transmitted, however, the author marks the parts with the order in which they should be displayed. The HTTP server (and the client's HTTP layer) can therefore remain entirely unmodified. The client's HTML parser, however, needs to be able to display sub-parts out of order, inserting blank space (or some other placeholder) where necessary to indicate missing pieces, and inserting these pieces as they arrive. As the retrieval progresses, the user may see parts of the document "expand" on the screen, the same way that Netscape fills in images. Or perhaps the browser could change some visual attribute of the placeholder (such as its color or texture), allowing the user to click on the placeholder to see the newly-arrived sub-part. The document could start with a (hidden) "table of contents" that shows the relative sizes of the parts. This would make it somewhat easier to pre-allocate screen space, although I imagine that in practice the allocation would be inexact. Of course, the right "solution" might be to encourage authors to provide their large documents in two forms: monolithic (single HTML file) for people with fast connections and/or for people who want to quickly search the documents for particular character strings, and "outlined", for people who want to retrieve just the parts they are looking for. -Jeff
Received on Tuesday, 21 March 1995 19:51:00 UTC