Re: Cascading HTML style sheets -- a proposal

Pei Wei (wei@ora.com)
Mon, 24 Oct 1994 19:45:13 -0400


Before this stylesheet talk freezes again, let me point out yet another
stylesheet proposal (enclosed below). The first time it was posted to
www-talk a year ago. At the time I think I had gotten like 3 or 4 replies
out of it. Maybe that'll be more interest this time :)

At this point, however, there is some preliminary implementation of the
stylesheet mechanism (in viola). The code is written as a library
independent of viola, so if this stylesheet mechanism is acceptable,
it shouldn't be hard for other browsers to reuse the code.

To see what it can do now, have a look at an actual example (screendump
of the effects, the markup used, and the influencing stylesheets):

http://pebble.berkeley.ora.com/vdoc/style/sample.html

Some random comments regarding H&kon's proposal:

I'm intrigued by the effects of the cascading effects. I've a feeling
that there'll be certain situation where this fuzzy mixing effect
would look interesting and useful. Like trying to tone down the
differences in font sizes from document to document so that there aren't
TOO many fonts being used. Quantization for font?

Also, the macro language could pehaps help to decide certain things.
Like it could help to decide switching to different presentation styles
depending on the condition of the browser? (not very considered comment)

Neat as it is, though, it seems like a big can or worm, especially at
this early point when we're tring to get people to use it at all.
I suggest such macro/scripting language be kept in mind, but postponed
for the first cut. Atleast until we've some experience with it a little.

As I'm experimenting with the stylesheets in violaWWW, I noticed that
by mixing different stylesheets, it's very easy to have the styles
clashing in a bad way. Consequently I end up using stylesheets to
take over the entire styling effects, or have to be very conscious of
the effects of the mixing.

Now, some questions which I had raised on Rob Raisch's stylesheet RFC.
The same questions seem to apply to yours as well:

With this language, how is context sensitivity dealt with? How do you
say that a paragraph's style differs depending on whether it's inside
of ADDRESS of not? Ie: there should be a way to specify that Paragraphs
inisde of ADDRESS should be aligned to the right, but would be aligned
to the left as by default. Note the P's and LI's in the sample stylesheet
below.

Here's that old stylesheet proposal.
(also in http://pebble.berkeley.ora.com/vdoc/style/stylesheetRFC.txt)
==========================================================================
Stylesheet RFC, Oct 23 1993 Pei Y. Wei (pei@ora.com)
O'Reilly & Associates

The first part of this document describes the language used to describe
the mapping between tags and style properties, and the interpretation
of the language.

The second part contains a style properties definition.

The third part describes the API to a library code for parsing
stylesheets and for resolving property queries, and sample API calls.

The Stylesheet Description Language
-----------------------------------

Everything not in quotes is case insensitive.

Sample stylesheet:

(HEAD,BODY fontSize=normal
BGColor=white
FGColor=black
(H1 fontSize=largest
BGColor=red
FGColor=white)
(H2 fontSize=large)
(P)
(A FGColor=red)
(CMD,KBD,SCREEN,LISTING,EXAMPLE fontSpacing=mono)
(BOLD,EMPH,STRONG fontWeight=bold)
(I fontSlant=italic)
(ADDRESS
(P fontSlant=italic))
(OL
(LI numStyle=roman
(LI numStyle=number
(LI numStyle=alpha)
)
)
)
(FOOTNOTE fontSize=small
(P)
)
)

>From this stylesheet, you can derive the following information:

* <P> inside of <HEAD> and <BODY> gets fontSize of "normal".
* <P> inside of <ADDRESS> gets italic slant font.
* <P> inside of <FOOTNOTE> gets a "small" font.
* List items in first, second, and third levels are numbered differently.
* Since <BOLD> and <STRONG> look the same, they are succintly lumpped
together.

Note that properties are inherited down the tree, unless overridden.
So, the color information that is specifed at the top is used all over,
except for <H1> which redefines its own colors.

Having this inheritance behaviour also helps to keep the description
short, as lots of information can be derived by the context in the
tree structure.

The lone "(P)"s are there to engage the respective <P> tags to be in
those particular contexts.

A document uses a <LINK REL="STYLE" HREF="URL_to_a_stylesheet">
to associate to a stylesheet. It's an open question as to whether
we should allow multiple stylesheets in a document, and where
this link can be specified (once only, in the <HEAD>?).
==========================================================================

One more thing not mentioned in the above RFC. There should be a way to
take attributes into account. For example, to make the following markup
be rendered with red text and boxed in orange border.

<P STYLE="WARNING">Spike on duty</P>

You'd write the style spec this way (in my syntax):

(P BGColor=white
FGColor=black
{STYLE "WARNING" FGColor=red
BDColor=orange})

BTW, because two of the three replies that I had got from my RFC was to
the effect of "use FOSSI or atleast SGML", I want to say that at this
point I'm treating my non-SGML stylesheet language as an experiment.
I'll probably convert the syntax into SGML (had started editing the
FOSSI DTD into something minimal). There are good reasons for using SGML
for this... so that's another thing to think about.

-Pei [catching up on my email]