Re: pages

Robert Partington (
Sun, 1 Jun 1997 00:57:27 -2300 (BST)

From: Robert Partington <>
Message-Id: <>
Subject: Re: pages
To: (Erik Aronesty)
Date: Sun, 1 Jun 1997 00:57:27 -2300 (BST)
In-Reply-To: <> from "Erik Aronesty" at May 31, 97 11:11:24 pm

> The concept of "pages" and "paged output" is an important one in 
> 	human understanding of readable content.
> Currently HTML is a "scrolling" medium without pages.
> Pages that are defined by browsers are arbitrary...and never take into
> account the fact that we like to see major headings on "their own page"
> (without the previous section's text visible on the screen).

that's the browsers problem - i can't see that it's hard to say "this is
a h1 class heading, stick it on the next page", but then a lot of the
things browsers don't do are easy(ish) to implement.  TeX does this kind
of page breaking well - they could copy the algorithm from there.

> The concept of "pages" is not applicable print-only, and browsers/index
> tools could benefit from <PAGE> tags by building appropriately paged 
> "tables of contents".

you could build the table of contents from the H* tags already - i'm
sure there's already at least one browser which offers a collapsible
view (just the headings), if not, then i'll probably hack it into lynx
when i get a spare weekend.  [ie4 and active-html can do this collapsible
page-headers as well, but that's not in wide use yet]

> Also, HTML prints very poorly and could benefit highly from a
> specified/implied.
> Without a specified page break it is impossible to build formatted
> reports that print well.
> It is also impossible to have a "print to fit" option in a browser.

using something like "<div class=page>" would indicate that this might
be a good place to break the page - but i don't think (again) that any
browsers actually support that, or that it's a particularly good idea
because you can't know how big the paper is, how big the printing font
is etc.  same as in html really.
rob partington / / sometime lynx hacker