Re: Cascading HTML style sheets -- a proposal

Bert Bos ([email protected])
Tue, 1 Nov 1994 16:35:00 +0100 (MET)


Dave Raggett writes:

|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,           ]####
####[ <[email protected]>            ]####[ Rijksuniversiteit Groningen ]####
####[ http://www.let.rug.nl/~bert/ ]####[ Postbus 716                 ]####
####[                              ]####[ NL-9700 AS GRONINGEN        ]####
####[______________________________]####[_____________________________]####