Re: HTML style sheets
C. M. Sperberg-McQueen (cmsmcq@uic.edu)
Fri, 04 Nov 94 15:31:56 CST
Message-Id: <9411042158.AA18682@dxmint.cern.ch>
Date: Fri, 04 Nov 94 15:31:56 CST
From: "C. M. Sperberg-McQueen" <cmsmcq@uic.edu>
Subject: Re: HTML style sheets
To: H&kon W Lie <howcome@dxcern.cern.ch>
Cc: www-html@www0.cern.ch
In-Reply-To: Your message of Thu, 3 Nov 1994 12:10:14 --100
On Thu, 3 Nov 1994 12:10:14 --100 you said:
>A brief summary of where we stand
>
>Consensus items:
>
> o Style sheets should provide a mapping between HTML elements and
> presentation parameters
> o Style sheets provide _hints_ that the browser may or may not take
> into account when rendering documents
> o Both the author and the user should be able to influence the final
> presentation
> o Style sheets should primarily be referenced from the HTML
> documents, not embedded.
All agreed. I'd put the final point even more strongly: they should
not be referenced from the HTML *document* at all; the link should be
external to the document, established in the HTTP header, not within
the HTML document.
>Items for discussion:
As an initial contribution to discussion, I'll give my immediate
reactions to these topics.
> o Should style sheets be HTML-specific or SGML-generic?
Generic. What gain is there to making them HTML-specific?
> o Can style sheets be blended?
In the sense that a user's local style sheets should be able to
modify or override the style sheet(s) associated with the document,
yes, definitely.
> o Should style sheets include logic?
The style sheet *language* certainly should. If some browser writers
refuse to implement it, their users will simply have lower function.
Critical to making the logic useful is a reasonable set of primitive
functions for querying one's location in the SGML document.
> o To what extent should the final presentation be predictable?
Given a style sheet or set of style sheets, and knowing the capacities
offered by the browser in question, there ought to be fairly little
doubt about things like font, size, highlighting, and layout. (Details
of the line breaking routine might make the lineation vary, but we
should be able to predict whether a block of text is going to be in
Times or in Helvetica (or in a system default font), whether it is
going to be bold or not, and where any hard line breaks will occur.
> o What presentation parameters do we want to control?
Font family, weight, style, size, treatment, color.
Text flow; shape of flowed text blocks; margins.
Vertical space before and after elements.
Display (or hiding) of text.
Literal strings (or strings containing attribute value text)
for insertion into the display before or after an element.
Actions to perform on click or double-click (for current WWW
clients, the only defined actions are:
follow-the-url-in-the-HREF-attribute
do-nothing
save-value-and-return-with-label-when-form-is-submitted
I hope to have a better list soon, after working through the DSSSL
spec. The items above are just a summary of what I came up with
trying to devise a set of primitives to describe the behavior of
HTML browsers as described in the HTML specification. (Original
text is at http://tigger.cc.uic.edu/~cmsmcq/style-primitives.html)
>Am I wrong? What's missing?
Basis to use for syntax. (Should the style sheet be an SGML document
using a specialized style-sheet DTD? I like this one a lot, since it
means we can use standard SGML editors for it. A data structure in
some existing notation? A C structure? A Scheme S-expression? I
like the notion of using Scheme, since it is used in DSSSL and is
clean and simple. A program or expression in an ad hoc language we
devise? This has the appeal of allowing the inventor the pleasure of
inventing a new language, but otherwise doesn't have much to recommend
it.)
Style to use for semantics. (Explicitly procedural? Explicitly
declarative? Try to ignore the issue and hope it can be handled
either way?)
Thanks for initiating this discussion.
-C. M. Sperberg-McQueen
Computer Center, Database Group
University of Illinois at Chicago