extrapolating just a bit from this line of experience, i concluded that
an html renderer (or www client) should allow the READER to
define how to render html constructs. for example, the reader should
it is something of a relief to imagine moving the display format
responsibility away from the information provider to the information
consumer (not the client program, but the reader herself), who should
actually be able to do a better job of it, since each reader knows
While I welcome the shift of emphasis from the information provider to
the consumer, the outlined policy has one major flaw: the presentation
becomes very boring. Yes, I like to be able to decide the font size
and family, but no -- I do not want to make presentation decisions
for every page I open. Consequently, all the H3 headlines I read are
Newspapers, on the other hand, are very conscious when selecting fonts
for headlines. The more important the articleis, the bigger font size
is used. If the content is "soft", a serif font is selected etc. So,
the visual presentation of information can not be entirely separated
from the content.
The conflict between the content of presentation and the preferences
of the reader has not been properly addressed yet. Either, the format
determines the final form presentation 100% (e.g. dtp formats), or the
responsibility is handed over to the reader/client application (e.g. html).
A better approach would be to let the information provider and the
consumer (represented by the client program) negotiate the final form
presentation. The information provider should be allowed to suggest
that "this piece of text is best presented using a hard font and
justified text". The client application could respond that, "yes, my
reader doesn't mind hard fonts, but absolutely hates justified text so
I'll go for ragged right instead". Etc etc.
All that is needed for the above outlined presentation scheme to
become possible is to make room for optional presentation hints when
defining a format. There goes my vote..
H&kon W Lie, Norwegian Telecom Research, firstname.lastname@example.org