W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1995

Re: proposal for a new html tag

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 21 Mar 95 19:43:44 PST
Message-Id: <9503220343.AA08517@acetes.pa.dec.com>
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 
    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.

Received on Tuesday, 21 March 1995 19:51:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:13 UTC