Thanks for your very useful comments and suggestions.
(The commented document can be found on
http://info.cern.ch/hypertext/WWW/People/howcome/p/cascade.html)
> 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?
Some attributes mix better that others. A typical use of "weighted
average" is to soften the author's attempt to be distinct, e.g the
suggested font sizes -- while the user still gets the message. One
doesn't _have_ to use this feature, but while "100%" is equal to a
binary "1" there is no going back from a binary syntax. In general,
I think computer interfaces are much too binary.
On the mixing of colors: yes, sometimes they will not mix too well. If
one specifies own colors, one should probably request dictatorship.
> 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
Often, the user needs to override a small number of attributes due to
a handicap, either on the part of equipment ("yuck, helvetica looks
ugly on this machine") or the user (e.g. colorblindness). But throwing
away all the author's style hints due such simple requests is a waste.
> 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.
No, the author does not know the age of the document since it changes
all the time :-) More on this below.
> - 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.
Probably so. Some of the features of the style sheet language will
primarily be used by authors, others primarily by users. However, I
think it's a sound principle to provide both groups with the same set
of tools. We're all both authors and users, right? This will also
simplify the implementation.
> - 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.
By saying "font.size *= 2" one does not refer to any previous
value. Instead one doubles a factor which is associated with the
attribute. The actual value (i.e. a point or pixel size) is not
determined until the browser has read all style sheets and is ready to
render. Then, the factor is multiplied in with whatever size the
attribute has been associated with.
> 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.
The grouping of elements is there to make the syntax less
verbose. Would 'h?.align' be better?
> 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.
There are two issues here. 1) the macro language, 2) server
vs. browser processing.
1) Instead of making all sites invent thir own macro processing
scheme, I think we should put it into the style sheet. This does make
the style sheet syntax/evaluation more complicated, but somebody's got
to do it..
2) A good principle when determining the presentation is that it
should take place as close as possible to the user, both spatially and
temporally, since one there will have more information available.
By enclosing logic in the style sheets, final decisions can be made
closer to the user. Cached style sheets will be more general and can
live longer. Also, this scheme requires no changes on the server side.
> 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.
Good idea. I'll add it.
> 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.
Agree, although I think most HTML publishers will use page description
language for the "highest quality".
> 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
I like the idea of using ID to specify a particular instance. I'm more
hesitant toward using case to carry information since HTML is
insensitive to case.
> 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.
I'll start making the list. For some of the more exotic media that one
can support with the current syntax, the list will not be finalized in
a couple of years. Some ideas:
medium = print | pixmap | screen | speech | tactile |
print_color | print_bw | print_3D |
pixmap_color | pixmap_bw | pixmap_gray |
speech_synthetic | speech_phoneme | speech_diphone |
braille
where the top row convenience groups are:
print = print_color & print_bw & print_3D
pixmap = pixmap_color & pixmap_bw & pixmap_gray
screen = pixmap & tty
speech = speech_synthetic & speech_phoneme & speech_diphone
tactile = braille & print_3D
For most settings, the unit of measurement would automatically select
the right medium, e.g.:
strong.weight = 50db # equals speech.strong.weight = 50 db
Some units, e.g. point size, is used for multiple media (paper and
pixmaps) and would require a distiction.
-h&kon