|Bert writes (Mon, 17 Oct):
|
|> I would classify the above as follows:
|
|> keep in HTML: remove to HSSL:
|> ------------- ---------------
|> UL WRAP=VERT TABLE BORDER
|> UL PLAIN CAPTION ALIGN=TOP
|> P NOWRAP H1 ALIGN=CENTER
|
|I don't agree with you here. What the style sheet is good for
|is to specify the appearence of the table border rather than its
|presence of absence for specific tables.
The criterium I used is this: can I think of a situation where having
a border changes the *meaning* of the table? If there are tables where
borders are more than just decorative, then the BORDER attribute
should definitely stay in HTML. If not,... well, I don't really mind.
|In my view, style sheets should allow authors to specify how the
|document is formatted at a range of window sizes, taking into
|account user preferences and platform limitations. The basic
|mechanism is to define style info as production rules.
|
|The left hand side of the production operates on:
|
| a) attribute values and tag names
|
| b) the context in which some element appears
|
| c) other parameters such as the age of the
| document and the current window size
|
| d) available resources, e.g. font name/size.
|
|The right hand side of the production specifies:
|
| a) nodal properties such as font name/size for
| some element, plus color and margin indents
|
| b) spatial relationships like above, below,
| left-of, right-of
I like this summary of input/output information. (a) and (b) are a
subset of ESIS. If you move `window size' from (c) to (d) then you can
make a distinction between document meta-info (c) and resources (d).
There is one other requirement implicit in all the proposals so far:
for as much as possible the formatting process is driven by the HTML
in the order that it is received. This ensures that a smart browser
can start formatting when the data is still coming in.
There are exceptions, of course, most notably tables and math. But
still this should be a good guideline in keeping the style language
simple. Note that DSSSL works quite differently. It assumes that the
whole of the document is available as a sort of random access
database, from which it selects the text to put in the next free
frame.
|The production is also associated with a weight following H&kon Lie's
|suggestion for cascading style sheets. I will be working with H&kon to
|refine this approach and implement it as part of the W3O testbed browser.
|We believe that it can be implemented efficiently and will lead to the
|ability to handle arbitrary SGML DTDs.
I've already expressed my doubt that styles *can* be combined with
such a simple mechanism. It reminds me of one of Donald Knuth's tricks
with his Metafont language: finding a font halfway between, say, Times
and Helvetica. (It is described somewhere in Douglas Hofstadter's
`Metamagical Themas')
However, I agree that it would be useful if there were an easy (for
the user and the machine) mechanism to change styles intuitively, for
example: `make less gaudy', `make colour-blind safe', `zoom in/out',
`reverse colours'. And I know a number of people who would be very
happy with the ability to view (almost) arbitrary SGML with at least
some formatting.
Bert
-- ___________________________________________________________________________ ####[ Bert Bos ]####[ Alfa-informatica, ]#### ####[ <bert@let.rug.nl> ]####[ Rijksuniversiteit Groningen ]#### ####[ http://www.let.rug.nl/~bert/ ]####[ Postbus 716 ]#### ####[ ]####[ NL-9700 AS GRONINGEN ]#### ####[______________________________]####[_____________________________]####