- From: Robert Partington <rjp@heffer.demon.co.uk>
- Date: Sun, 1 Jun 1997 00:57:27 -2300 (BST)
- To: earonesty@montgomery.com (Erik Aronesty)
- Cc: www-html@w3.org
> > 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 / rjp@browser.org / sometime lynx hacker
Received on Sunday, 1 June 1997 04:55:51 UTC