> > I am not sure yet whether you can
> > design something that's optimally designed for a 24x80 ascii screen
> > and also for paper (probably not) but at least it'll be usable in both
> > contexts.
>
>
> Do you feel that
>
> (a) you need more variety of tags, or that
> (b) the 24x80 representation of the existing tags is suboptimal, or that
> (c) the task is impossible by its nature -- you must rewritethe document.
>
> If (a), we should take that into account for HTML extentions.
> If (b), you can change the DefaultStyles.c built-in style sheet
> If (c), I agree. In principle. But In practice we need to comprompize.
>
> Tim
The main goal of SGML and one which I believe it meets reasonably well is
the seperation of display issues from content issues.
Presentation issues can only be guessed at, never known.
Only by decoupling the presentation of information from it's organisation
can we hope to develop useful tools. (IMHO)
A simple example might be the rendering of a list. How would you do it?
A "LIST" is nothing more than a collection of items. There should be no
inherent assumptions as to how it might be rendered.
I could conceive of a block of text containing the first element, and an
indication that there were more elements available (via some user
interaction).
Or even the complete collapse of the list into just an indication of it's
existance, (a "jump").
The point should be (IMHO) that the rendering decision should ALWAYS be
left to the client. Any rendering-centric portions of HGML should be
replaced by more general constructs.
Perhaps what we need is a WG to design the next generation of HGML? Is
there such a beast already?
</rr>
--
I hate 3 things: Ignorance, Poverty, and Moving. Well, maybe not in that order.