- From: C. M. Sperberg-McQueen <cmsmcq@uic.edu>
- Date: Fri, 04 Nov 94 15:31:56 CST
- To: H&kon W Lie <howcome@dxcern.cern.ch>
- Cc: www-html@www0.cern.ch
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
Received on Friday, 4 November 1994 22:59:01 UTC