The idea that two designs can be averaged to come up with an
intermediate style seems utterly wrong to me. What happens when my
blue-on-yellow style is combined with somebody else's yellow-on-blue?
Do I get green-on-green? Or who wants to look at a page with
Avant-garde titles over Helvetica paragraphs?
Design is far too subtle for that and combining styles is almost
impossible. Unless you want to endow the browser with a lot of
artifical intelligence, there are only three reasonable possibilities:
1. neither the document nor the user expresses any preference
2. the document specifies a style sheet
3. the user specifies a style sheet
In case 1, the browser's configuration determines the default style.
Case 3 has priority over case 2.
Expressions in the style specification that are to be evaluated by the
browser make the language far too difficult. Besides, I don't think
there is any need for them.
- The document's author knows the AGE of the document, it's up to
him to specify the corresponding style. He can use whatever means
he wants, including a macro pre-processor.
- Selecting a style based on RELEVANCE is an issue for the browser
and the user, the document's author shouldn't try to base his
design on RELEVANCE.
- Specifying a font size as twice its previous value is meaningless
in a style language where the order of the specifications is
unimportant: either a specification applies or it doesn't.
Having two different names for the same property is confusing.
E.g.: `head.align' instead of the six terms `h1.align'...
`h6.align'. Besides `head' is also the name of an HTML element.
Allowing style sheets to be loaded anywhere else than in the HEAD not
only leads to ugly lay-outs and difficult to maintain documents, it is
also unnecessary if the ID attribute of elements is used (see below).
These are the changes I propose:
The rules for cascading of style sheets are as follows:
1. When the user selects one of his own style sheets, the LINK'ed
style sheets are ignored.
2. Otherwise, all LINK'ed styles are loaded in order, combining
their rules as follows (cf. the X resources):
a. specific overrules general, i.e., rules with wildcards give
way to rules without them.
b. if two specifications are the same, the one encountered first
will take precedence.
3. Style sheets that are included from other style sheets are
treated as if they were literally included at the position where
they are referenced.
Rules allow no expressions. When the designer finds it convenient to
work with macros or expressions, he should arrange to apply a macro
processor to the style sheet before the server sends it out.
I would like to introduce a new type of value: an indirect value
specified as a URL, e.g.: body.background =
@http://some.where/rice-paper.xpm. Maybe this is only allowed for
certain properties.
The `cascading style sheets' may well grow to become quite
complicated, but in theory they are meant for designs that do not
demand the highest quality. That means that there must be room for
linking additional style sheets in different languages for browsers
(or printer drivers) with sophisticated formatters. I suggest that the
syntax of the LINK element is changed to allow, e.g.:
<LINK REL="style/hssl" HREF="simple.style">
<LINK REL="style/dsssl" HREF="complex.style">
The browser chooses an appropriate one. Alternatively, the browser
retrieves all style sheets and then decides on the basis of their
Content-Type, but that is somewhat inefficient.
Rules can be attached to generic elements (`classes') or to specific
ones. I suggest the same convention as in the X resource database: a
capitalized first letter indicates all instances of an element,
lowercase indicates a particular instance. Instances are referred to
by their ID. Compare:
P.align para27.align
Div1.font.size scr_div.font.size
H1.above ch2_title.above
(Difficulty: IDs may include a `.') I'm not sure whether the
uppercase-rule should be a convention or an integral part of the
syntax.
Elements in HTML can have attributes that influence the lay-out, such
as <OL COMPACT> or <P ALIGN=LEFT>. The best way would be to remove
those attributes from HTML. If necessary, we could introduce new GI's
instead of those attributes that also have a semantic function, as in
the case of <UL WRAP=VERT>
The proposal is definitely worth developing further. It would make the
discussion easier if there was also a list of all the properties of
all elements. That list will evolve, of course, but then at least we
can check if all the properties fit into the proposed syntax. I'm
especially interested in the supported media types: display, printer,
speech synthesizer, etc.
Thanks for the work, Hakon!
|A proposal for an HTML style sheet scheme is available from
|
|http://info.cern.ch/hypertext/WWW/People/howcome/p/cascade.html
Bert
-- ___________________________________________________________________________ ####[ Bert Bos ]####[ Alfa-informatica, ]#### ####[ <[email protected]> ]####[ Rijksuniversiteit Groningen ]#### ####[ http://www.let.rug.nl/~bert/ ]####[ Postbus 716 ]#### ####[ ]####[ NL-9700 AS GRONINGEN ]#### ####[______________________________]####[_____________________________]####