This is arguable.
> Things like searching, printing, saving, etc.
> don't work very well.
Searching works fine, for example using web traversing robots. Obviously search
'in file' won't work if you split it up into several files - if search is
important, making each html file a searchable index with the search engine
looking over the whole document.
Printing a tree structured document is clearly a problem, but not
insurmountable. Browsers would need to be a bit more clever in retrieving
referenced files and linearising a tree for printing. Saving a file works. If
you want to save a reference to the top of a document tree, save the top node.
Of course, saving local copies of documents goes against the Web philosophy. How
do you know that your copy matches the original? If you want to save a document
for future reference, save the URL. If network latency or bandwidth is a
problem, use a proxy.
>Mosaic doesn't even save inlined images when
>documents are saved as hypertext!
Sigh. Mosaic questions to ... of course it saves the HTML, so all links -
whether to images or other html files or whatever - are not retrieved and saved.
However, Mosaic 2.4 for X does not insert BASE tags so relative links often fail
with saved documents. This is however a minor implementation detail of one
browser; your original questions seemed to be referring to the authoring process
rather than the precise interactions with a particular browser.
> Browsers need to improve to the
> point where a reader is unaware they've crossed a "document" boundary.
> Well, it should be smoother at least...
Agree. However these improvements are all do-able with the current
specification. There is nothing to prevent a printing function, for example,
optionally getting linked documents by some search strategy - only one hop, on
the same server as the base document, for example - and composing these into a
single printable file.
> I assume that you define "section" to be "one of the units of information
> that the current topic is decomposed into."
No.
I was using the word "section" in precisely the way you had used it in your
original message, which divided the levels of a conceptual document into
Chapter, section, subsection and clarification if memory serves. Your choice of
terms, not mine. Given that, perhaps you should read my original reply again.
> Then you suggest that header
> levels reflect the physical nesting of sections within the same document,
> right?
Yes.
> Take document to mean "the contiguous unit of hypertext that gets
> loaded into a browser.")
Actually I was taking "document" to mean a conceptual monolithic document with
the four levels of heading that you originally specified. Whether this is
delivered as one html file or several is a matter of implementation. I have used
"file" or "html file" as meaning "the contiguous unit of hypertext that gets
loaded into a browser."
> You also seem to recomend that header levels
> should be "reset" to <h1> with every new document.
Yes, otherwise the headings get lost in deeply nested documents. Also, it means
that each delivered html file has an H1 as its first header, ie each file is
valid HTML. If you deliver a document that starts h3, it is not valid (but it
will have lots of company ;-) )
> I think this is style that looks best --- I format my documents like this.
This is also the style that Webmaker tends to produce. I like it, too.
> Does this have any impact on automatic table of contents generators?
Not if you generate the TOC from the original, conceptual monolithic document.
> Chris and I differ greatly on the use of navigational components in the text.
Possibly
> Things like "on to", "up to", "next", "previous", etc. I personally don't
> like these mechanisms because the traversal history stored in the reader's
> browser often doesn't match what the author intended.
Um. I know what you mean, and agree to some extent. I hate seeing a link that
says back to blah - or, worse, back - because I may not have come by that route.
On the other hand, being able to navigate through a tree structured document
using such buttons is handy. That is why, if you look at my original examples,
my buttons did *not* say back, next, etc.
They said "Up to {chapter title}", and so on. In other words, they clearly said
that they were related to the logical structure of a document, as opposed to the
traversal history taken by a particular viewer. To my mind, provided these
concepts are kept separate, there is no problem.
> I
> think HTML+ will help solve this by providing the hints browser needs to
> maintain that structure mapping automatically.
> How do others feel about navigational aids?
Actually, my reading of Dave Raggetts paper at WWW94 lead me to believe that
GTML+ tries to blur the distinction between logical document structural
nvigation and browsing history navigation. I would rather keep these concepts
clearly separate.
--
Chris Lilley
+--------------------------------------------------------------------------+
|Technical Author, ITTI Computer Graphics & Visualisation Training Project |
+--------------------------------------------------------------------------+
| Computer Graphics Unit, | Internet: C.C.Lilley@mcc.ac.uk |
| Manchester Computing Centre, | Janet: C.C.Lilley@uk.ac.mcc |
| Oxford Road, | Voice: +44 61 275 6045 |
| Manchester, UK. M13 9PL | Fax: +44 61 275 6040 |
| X400: /I=c/S=lilley/O=manchester-computing-centre/PRMD=UK.AC/ADMD= /C=GB/|
| <A HREF="http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html">my page</A> |
+--------------------------------------------------------------------------+