- From: Liam Relihan <relihanl@ul.ie>
- Date: Mon, 20 Mar 1995 14:11:48 +0000 (GMT)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Mon, 20 Mar 1995, Siegmann P wrote: > Name of the tag : <LP> and its </LP> counterpart > Mnemonics : Lower Priority > What does it do : This new tag is an attempt at giving the author of an html > document the possibilty to give a relative priority to different parts > of his document. > > 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. > > For example: > Here is a document describing a better mousetrap, and I, as the author, think > that the reader should at least have read all my headers and the abstract. > The text between the headers is considered less important. > And as formal proofs are so impopular, the proof that my mousetrap really > works has an even lower priority. > > <HTML><HEAD><TITLE>Mousetrap</TITLE></HEAD> > <BODY><H1>My better mousetrap</H1> > <BLOCKQUOTE> > <H2>Abstract</H2> > This is a proposal for a better mousetrap > </BLOCKQUOTE> > <H2>Introduction</H2> > <LP> <!-- HERE the priority is lowered--> > This is an idea that > blahblahblahblah > </LP> <!-- HERE the priority is raised again--> > <H2>How it works</H2> > <LP> <!-- HERE the priority is lowered--> > It works like this.... > <LP> <!-- HERE the priority is lowered even more--> > <H3>The formal proof</H3> > And this is the formal proof that it really works: > .... > </LP> <!-- HERE the priority is raised to the level of -1 --> > Lo and behold, it works. > </LP> <!-- HERE the priority is raised to the begin level--> > <ADDDRESS><A HREF="mailto:psiegma@cs.vu.nl">Paul Siegmann</A></ADDRESS> > </BODY></HTML> > > Now the viewer, or the person viewing the document could have several options: > - Fast network connection: > Ignore the priorities. > - Medium network connection/curious person > First load all the document parts with the highest priority, and > automatically continue loading the rest of the document in order of > priority. > - Slow network/modem connection: > Only show the parts with the highest priority, and only show parts > with a lower priority if they are clicked on (like with delayed image > loading) > > All comments and suggestions welcome. Paul... I suspect that this message would be best dealt with on the HTML mailing list - anyone have the address handy ? As regards your tag, I would have my doubts about the partition of documents based on the speed of network connections --- I reckon that the encoding of a document should be as independent as possible of its storage and its transmission. Maybe if you had some other rationale for the partitioning of documents.... Besides, I think authoring is such a problem in W3 already, that allowing 3 sub-documents within one document is only going to mean messier documents and much increased workloads for document authors and maintainers. What about a special summary tag ? Doesn't the latest version of HTML have provision for this sort of thing ? Liam -- Liam Relihan, Voice: +353-61-202713 CSIS, Schumann Building, [space] Fax: +353-61-330876 University Of Limerick, E-mail: relihanl@ul.ie Ireland. http://itdsrv1.ul.ie/PERSONNEL/lrelihan.html
Received on Monday, 20 March 1995 06:18:31 UTC